Date: Mon, 11 May 2009 12:24:26 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Ed Schouten <ed@80386.nl>, jt@0xabadba.be, vasanth raonaik <vasanth.raonaik@gmail.com> Subject: Re: concurrent sysctl implementation Message-ID: <200905111224.26856.jhb@freebsd.org> 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
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 > 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. Well, one compromise might be to allow concurrent userland requests if the buffer size is small (say < 1 page). This would be a quite simple change and would cover many common syscalls like fetching an int which don't wire memory anyway. > - 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. I don't think further work is needed here for the tree, notice that in-kernel sysctls are already concurrent and use a read lock on the tree. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905111224.26856.jhb>