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. BruceReceived on Thu Mar 04 2004 - 05:41:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:46 UTC