Subject: Re: uvm_vslock / uvm_vsunlock problems
To: Simon Burge <simonb@wasabisystems.com>
From: Stephan Uphoff <ups@stups.com>
List: tech-kern
Date: 07/10/2003 23:49:23
Hi Simon,

Simon Burge wrote:
> Hi Stephan,
> 
> Stephan Uphoff wrote:
> > [ ... ]
> >
> > Solutions:
> > ----------
> > sys___sysctl can probably use a kernel buffer for the (hopefully few) 
> > occasions
> > where copying is not allowed to block. (And copyout from the kernel buffer
> > when it is save to do so)
> > ( I assume this is the reason for the wiring but was too lazy to verify ) 
> 
> At least for the sysctl case, we could be talking about a reasonably
> significant chunk of memory here - ps's fetching of the process table
> comes to mind.  On my home server, this is 225 processes * 608 bytes
> = 136kB right now.  It seems silly to malloc all that when the user
> program has that storage available too.
> 
> Or am I misunderstanding what you're suggesting?

Unfortunately no.

(If fetching the process table absolutely requires that copyout does not
sleep.)

Even more painful than the additional memory pages required is probably
the need to map the stuff into the kernel.
Since virtual memory space can be extremely tight on 32bit systems you
might not be able to map the whole thing and end up using some windowing
scheme.

This definitely SHOULD be fixed without bouncing buffers.
However even fixing physio will be hard - and physio does not really need
the user virtual address space once it has access to the physical pages.
Usage of a non-sleeping copyout in sysctl would require the ability to freeze
the virtual address space (including pmap) of the process.

Maybe a copyout with fail on fault ? (And retry?)

Sorry I don't even have an ugly fix.

	Stephan


PS: Allowing any process to force the kernel to wire unlimited 
number of pages is just wrong. (What happens when the kernel runs 
out of pages?)