From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 16:49:42 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 8325E1065676 for ; Mon, 11 May 2009 16:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 543118FC1E for ; Mon, 11 May 2009 16:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 055EF46B8B; Mon, 11 May 2009 12:49:42 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C2A2B8A025; Mon, 11 May 2009 12:49:40 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 11 May 2009 12:24:26 -0400 User-Agent: KMail/1.9.7 References: <20090508214117.GY58540@hoeg.nl> In-Reply-To: <20090508214117.GY58540@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111224.26856.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 11 May 2009 12:49:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ed Schouten , jt@0xabadba.be, vasanth raonaik 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 16:49:42 -0000 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