Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 May 2009 23:34:26 +0200
From:      Ed Schouten <ed@80386.nl>
To:        John Baldwin <jhb@freebsd.org>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, jt@0xabadba.be
Subject:   Re: concurrent sysctl implementation
Message-ID:  <20090514213426.GP58540@hoeg.nl>
In-Reply-To: <200905111801.18767.jhb@freebsd.org>
References:  <a0806f900905050107u4cbf0624oc83aafa54ae651f0@mail.gmail.com> <200905111224.26856.jhb@freebsd.org> <a0806f900905111127p378628bbw89e1d45f087e558e@mail.gmail.com> <200905111801.18767.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--FbCNvfVkhudvi8fu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* John Baldwin <jhb@freebsd.org> 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 <ed@80386.nl>
 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090514213426.GP58540>