Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 May 2009 20:13:32 -0400
From:      jt@0xabadba.be
To:        Ed Schouten <ed@80386.nl>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, vasanth raonaik <vasanth.raonaik@gmail.com>
Subject:   Re: concurrent sysctl implementation
Message-ID:  <3C2B6A87-C127-4E1F-9A1E-DADF613B18BF@0xabadba.be>
In-Reply-To: <20090508214117.GY58540@hoeg.nl>
References:  <a0806f900905050107u4cbf0624oc83aafa54ae651f0@mail.gmail.com> <d9f479c10905050239u5d6d8304y1f63e41eabee8624@mail.gmail.com> <20090508214117.GY58540@hoeg.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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@80386.nl> wrote:

> Hi,
>
> * vasanth raonaik <vasanth.raonaik@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@80386.nl>
> WWW: http://80386.nl/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C2B6A87-C127-4E1F-9A1E-DADF613B18BF>