From owner-freebsd-hackers@FreeBSD.ORG Thu May 14 21:34:27 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 79643106564A; Thu, 14 May 2009 21:34:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAEF8FC13; Thu, 14 May 2009 21:34:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9E5381D17D; Thu, 14 May 2009 23:34:26 +0200 (CEST) Date: Thu, 14 May 2009 23:34:26 +0200 From: Ed Schouten To: John Baldwin Message-ID: <20090514213426.GP58540@hoeg.nl> References: <200905111224.26856.jhb@freebsd.org> <200905111801.18767.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FbCNvfVkhudvi8fu" Content-Disposition: inline In-Reply-To: <200905111801.18767.jhb@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Hackers , jt@0xabadba.be 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: Thu, 14 May 2009 21:34:27 -0000 --FbCNvfVkhudvi8fu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * John Baldwin wrote: > Well, in theory a bunch of "small" requests to SYSCTL_PROC() nodes that u= sed=20 > sysctl_wire_old() (or whatever it is called) could cause the amount of us= er=20 > memory wired for sysctls to grow unbounded. Thus, allowing this limited= =20 > concurrency is a tradeoff as there is a minimal (perhaps only theoretical= at=20 > the moment) risk of removing the safety net. >=20 > The patch is quite small, btw, because the locking for the sysctl tree al= ready=20 > exists, and by using read locks, one can already allow concurrent sysctl= =20 > requests. There is no need to add any new locks or restructure the sysct= l=20 > tree, just to adjust the locking that is already present. It might be=20 > clearer, in fact, to split the sysctl memory lock back out into a separat= e=20 > lock. This would allow "small" sysctl requests to run concurrently with = a=20 > single "large" request whereas in my suggestion in the earlier e-mail,=20 > the "large" request will block all other user requests until it finishes. >=20 > I've actually gone ahead and done this below. Boohoo. I actually wanted jt to work on this, as a small exercise to figure out the way locking primitives work in the kernel. No problem, because I can think of dozens of other things. Is there a chance we can see this patch in 8.0? I like it that the memlock is being picked up before we pick up the sysctl lock itself, which makes a lot of sense. --=20 Ed Schouten WWW: http://80386.nl/ --FbCNvfVkhudvi8fu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoMjmIACgkQ52SDGA2eCwW0hACbB/4W3DshwsRPIuaXta+Wl8IX Y34An1UveDTp8oQMQb8jOCiMAgaTk2ve =vX/X -----END PGP SIGNATURE----- --FbCNvfVkhudvi8fu--