>From: thorpej@zembu.com (Jason R Thorpe)
>Subject: PT page stealing -- should we bother?

>Now that uvm_fault() can do this, the need to steal resources
>from other pmaps is basically gone, and we can simply let
>UVM simply manage all of that.

i'm not so sure about this.  i'm somewhat reluctant to remove error
handling code (which is what the stealing stuff is) even if it doesn't
run often (in the common case).

prior to the introduction of the PMAP_CANFAIL flag, all VM code
assumed that pmap_enter() would always be a success.   that means that
memory allocation within pmap_enter() was not allowed to fail.

then the PMAP_CANFAIL flag was added.   if set, this allows
pmap_enter() to fail and return a false status value.   there are a
couple of points (in uvm_fault) where it makes sense to allow
pmap_enter failure... for a user fault you can simply put the process
to sleep and wake the pagedaemon.

specifically, the following pmap_enter() were converted to
PMAP_CANFAIL, and i agree with the logic behind it:
  1. device pager fault routine - if it fails, put user process to
    sleep and try again
  2. uvm_fault: faulting neighborhood pages that are close to (but not 
    the faulting page)
  3. uvm_fault: on anonymous page  (same logic as 1)
  4. uvm_Fault: on object page (same logic as 1)

one of the issues left in my mind is what about the remaining
pmap_enter() calls that were not converted to PMAP_CANFAIL?  would
removing the error protection open the kernel up more to an attack by
a malicious program (esp related to kernel memory allocation)?
looking at the code there are plain calls in uvm_bio.c, uvm_km.c, and
uvm_pager.c.


the nice thing about that code is that it is fairly isolated (just
within pmap) so it isn't such a bother.



>From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld)
>Subject: Re: PT page stealing -- should we bother?

>It's also worth noting that I added a printf to the PTP steal path on
>the i386mp branch, and I've never actually seen that printf happen on
>my MP test machine, even under relatively heavy load; it's much more
>likely that processes get SIGKILLed from lack of swap..

>So, at least on x86, the ptp-stealing code path is large, complex,
>runs extremely rarely, and is no longer necessary for correct
>operation even under extreme stress.  Sounds like a perfect candidate
>for elimination.

in ideal conditions that code shouldn't be running anyway, so i'm not
surprised that your printf didn't fire.  it is there to protect from
error conditions that don't normally occur.  certainly the
PMAP_CANFAIL reduced the chances of them occurring, but i'm not sure
that the chances have been reduced all the way to zero.  i'm also not
sure what effect starting to make use of some of uvm's newer features
will have.  i would like to see that happen before pruning out this
type of code.


chuck
-- 
Chuck Cranor                            http://www.research.att.com/info/chuck
Senior Technical Staff Member		chuck@research.att.com
Internet and Networking Systems Research Lab
AT&T Labs-Research, Florham Park, NJ