Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Mar 2004 01:41:32 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Don Lewis <truckman@freebsd.org>
Cc:        rwatson@freebsd.org
Subject:   Re: sysctl spinning (was: Re: ps Causes Hard Hang)
Message-ID:  <20040305012433.B9033@gamplex.bde.org>
In-Reply-To: <200403041307.i24D7P7E004328@gw.catspoiler.org>
References:  <200403041307.i24D7P7E004328@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Mar 2004, Don Lewis wrote:

> I just checked the mlock() man page in the Single UNIX Specification
> Version 3.  Our mlock() implementation is broken.  We should be
> returning ENOMEM here, though this will result in some sort of user
> visible sysctl breakage instead of a tight loop.

POSIX is more authoritative.  It says that ENOMEM may be returned if
an implementation-defined limit would be exceeded, and that EAGAIN
shall be returned if some or all of the memory could not be locked
when the call was made.  So it literally requires returning EAGAIN
even when the limit would be exceeded, but it doesn't mean to require
that.

> > I think EAGAIN was only meant for retrying after transient changes
> > to the data.
>
> I think there may be legitimate cases where our memory wiring
> implementation would legitimately want to return EAGAIN and not cause a
> tight loop, but there is currently no way to distinguish this from the
> case that you mention.

I think it should return EAGAIN except when certain limits including the
rlimit would be exceeded.  The rlimit is often large or infinity, so
it must be easy to exceed the system-wide limit if lots of processes uses
locked memory.  Perhaps every process should be guaranteed a few pages of
locked memory so that most systctls always work.  This is like guaranteeing
that a minimum number of files (20 or so) can be opened, but I don't
believe we even guarantee that, especially when the files are pipes
wanting 64K of wired memory each.

Bruce



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