Date: Mon, 11 May 2009 14:27:48 -0400 From: jt@0xabadba.be To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: concurrent sysctl implementation Message-ID: <a0806f900905111127p378628bbw89e1d45f087e558e@mail.gmail.com> In-Reply-To: <200905111224.26856.jhb@freebsd.org> References: <a0806f900905050107u4cbf0624oc83aafa54ae651f0@mail.gmail.com> <d9f479c10905050239u5d6d8304y1f63e41eabee8624@mail.gmail.com> <20090508214117.GY58540@hoeg.nl> <200905111224.26856.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John,
Thank you for your input on this matter, I'm excited to write
some software for this project since its given me great code to learn
from as i've grown up (still a kid though :). My questions are a bit
more detailed below.
On Mon, May 11, 2009 at 12:24 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Friday 08 May 2009 5:41:17 pm Ed Schouten wrote:
>> A solution would be to solve it as follows:
>>
>> - Use a semaphore, initialized to some insane high value to put an upper
>> =A0 limit on the amount of concurrent sysctl calls. I'm not sure whether
>> =A0 this is really needed. Maybe this issue is not as serious as we thin=
k
>> =A0 it is.
>
> Well, one compromise might be to allow concurrent userland requests if th=
e
> buffer size is small (say < 1 page). =A0This would be a quite simple chan=
ge and
> would cover many common syscalls like fetching an int which don't wire me=
mory
> anyway.
Why is this a compromise? Isn't concurrent sysctl calls from userland
a good thing? What materials would be good to read other than the
code and the sysctl manual pages? You said it would be relatively
easy to implement this; what methods should I be considering to do
this in and what part of the code specifically should I be looking at?
>
>> - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up
>> =A0 the lock when we traverse parts of the sysctl tree that has
>> =A0 dynamically created entries.
>
> I don't think further work is needed here for the tree, notice that in-ke=
rnel
> sysctls are already concurrent and use a read lock on the tree.
yes i've seen the locking mechanism, it reminds me of a monitor type
system... though from my understanding monitors appear seldom compared
to semaphores in the kernel. I assume the lock will need a bit of
twiddling with in some areas of the code if I'm going to enable
concurrency from userland, when its said that we should consider the
things that are dynamic would it be better to implement this with more
than one "queue" or list? Instead perhaps break them up into several
lists or, more fundamentally, two lists -- those that are dynamically
created entries and those that are not -- is this even feasible to
distinguish between the two originally and then on the fly later?
Thanks a lot!
Respectfully,
/jt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a0806f900905111127p378628bbw89e1d45f087e558e>