hi jason,

I agree that this change isn't perfect, but it is Vastly Better than the
previous work-around.  I do plan to continue working on a better solution,
but since I have no idea when that will be ready, it seems worthwhile to
go with the improvement in the meantime.

but really, having ntpd call mlockall() on a low-memory system at all
doesn't seem like a very good idea to begin with.  I'm sure that ntpd
doesn't use most of libc, so wiring down all those pages that don't really
need to be wired for ntpd is a waste.  similarly, I'm sure that ntpd
uses only a small part of its stack limit, yet the whole stack is
allocated and wired down.  if we really need to reduce the amount of
memory wired down by ntpd in the short term, linking ntpd statically
and reducing its stack limit would probably be the best way to do it.
it's probably not that important, though, since on really low-memory
systems, mlockall() fails anyway, so it's not an issue there.

-Chuck


On Mon, Dec 31, 2001 at 02:54:26PM -0800, Jason R Thorpe wrote:
> On Tue, Jan 01, 2002 at 12:34:41AM +0200, Chuck Silvers wrote:
> 
>  > this change has the effect of causing MAP_PRIVATE mappings to be
>  > copied to anonymous memory when they are mlock()d, so that uvm_fault()
>  > doesn't need to copy these pages later when called from ptrace(), thus
>  > avoiding the call to pmap_page_protect() and the panic that results
>  > from this when the mlock()d region is unlocked or freed.  note that
>  > this change doesn't help the case where the wired mapping is MAP_SHARED.
> 
> This is Bad.  Running ntpd is now going to cause the entire libc to
> be wired down into anonymous memory without any hope of sharing it
> with other libc-using processes.  This is a real screw for low-memory
> systems.
> 
> -- 
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>