Re: [RFC] Arch option to touch newly allocated pages

[Daniel Phillips <phillips@bonn-fries.net>]

On March 7, 2002 05:50 pm, yodaiken@fsmlabs.com wrote:
> On Thu, Mar 07, 2002 at 04:31:10PM +0100, Daniel Phillips wrote:
> > > > > Why is that a fix? And how can it work?
> > > > 
> > > > Since there is always at least one freeable page in the system (or we're oom) then
> > > > we just have to find it and we know we can forcibly unmap it.  We do need to know
> > > > the total of pinned pages, I should have said locked/dirty/pinned.
> > > 
> > > What if we are oom?
> > 
> > This problem didn't get any worse, we still have to deal with it.  We can wait, so
> > we deal with it in the standard way (i.e., we puke, have to do something about that.)
> 
> So it can return NULL? 

Returning null here won't help if the caller doesn't have a fallback, or if the fallback
is unacceptable, such as losing a filesystem transaction.

> > > What if we are on our way to deadlock?
> > 
> > huh??
> 
> Process A needs 4 pages, Process B needs 4 pages, each grabs 3.

This is no new deadlock.  Supposing each has successfully grabbed 3, what
good does it do if the process is too clueless to release the pages it's
already grabbed, because the 4th page alloc fails?  (The first 3 may have
been alloced in a completely different part of the program.)  And if the
process does know how to do this, it should tell the VM that *then* the VM
should feel free to fail it.

> One easy, traditional unix algorithm for dealing with this is
> 	for(i=0; i < 4; i++)if !(p[i]=kmallloc(...))
>                                 free all that we have so far

Just or in GFP_ok_to_fail there.

> > > What if the caller of kmalloc will make less good use of the page
> > > than the current owner of the page?
> > 
> > That's life, that's what lrus are for.
> 
> Really? I thought LRUs were to approximate working sets. Obviously
> if a program is kmallocing its working set is changing but that
> does not tell us anything about whether it is a correct decision to
> rip a page from the working set of another process.

We're getting way far from the original question here.  Our lru has no
concept of working set, it's completely global.  That's not so great and
it's another problem to tackle.  Sometime.

> > You won't find one if you don't look for it.
> 
> I'm too dumb to come up with a solution here, but you are the one
> changing the interface, so surely you have a couple of "less borked"
> solutions in mind - right?

Yes.  Well, I'm not alone here, ping Marcelo on that if you like.  This is
known borkness that's been deferred while more pressing borkness is dealt
with.

-- 
Daniel