Hi, * vasanth raonaik <vasanth.raon...@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 <e...@80386.nl> WWW: http://80386.nl/
pgpVFgnEuH1Cq.pgp
Description: PGP signature