From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 18:28:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0976A1065672 for ; Mon, 11 May 2009 18:28:10 +0000 (UTC) (envelope-from jt@0xabadba.be) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7312C8FC0C for ; Mon, 11 May 2009 18:28:09 +0000 (UTC) (envelope-from jt@0xabadba.be) Received: by ey-out-2122.google.com with SMTP id 9so913789eyd.7 for ; Mon, 11 May 2009 11:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.19.198 with SMTP id n48mr3577774wen.41.1242066488158; Mon, 11 May 2009 11:28:08 -0700 (PDT) X-Originating-IP: [192.52.218.45] In-Reply-To: <200905111224.26856.jhb@freebsd.org> References: <20090508214117.GY58540@hoeg.nl> <200905111224.26856.jhb@freebsd.org> From: jt@0xabadba.be Date: Mon, 11 May 2009 14:27:48 -0400 Message-ID: To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 18:28:10 -0000 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 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