concurrent sysctl implementation

[Ed Schouten]

Hi,

* vasanth raonaik <vasanth.raonaik at gmail.com> wrote:
> Hello Jt,
> 
> I am a newbee in this alias. I am having a very basic question. It would be
> really good if you could give me some of this information.
> Could you please elaborate on what is the current architecture of sysctl
> implementation and How the concurrency would benefit us.

Right now sysctl is synchronized using the sysctl lock. The problem is
that certain sysctls just block for a very long time (especially some of
the GEOM ones). We also call sysctl when we execute new processes, to
obtain a random number for the stack protector. This means we have quite
a lot of contention on it. This lock needs to be there, because sysctls
can be added and removed on demand.

I think I discussed this with John Baldwin (right?) and I think we also
have the issue that we cannot allow an unbounded amount of concurrent
calls to sysctl, because sysctl wires memory.

A solution would be to solve it as follows:

- Use a semaphore, initialized to some insane high value to put an upper
  limit on the amount of concurrent sysctl calls. I'm not sure whether
  this is really needed. Maybe this issue is not as serious as we think
  it is.

- Use an rw/rm/sxlock to protect the sysctl tree, but only pick up
  the lock when we traverse parts of the sysctl tree that has
  dynamically created entries.

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090508/f1271d7d/attachment.pgp