concurrent sysctl implementation

[jt at 0xabadba.be]

Ed,
    Thanks :) I'll be implementing this as discussed over the next few  
months thanks for the technical detail I've been extremely busy with  
finals. I will write the list with my thoughts within the next week,  
sorry for the delay.

=jt

On May 8, 2009, at 17:41, Ed Schouten <ed at 80386.nl> wrote:

> 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/