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

[yodaiken@fsmlabs.com]

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? 

> 
> > What if we are on our way to deadlock?
> 
> huh??

Process A needs 4 pages, Process B needs 4 pages, each grabs 3.
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


> > 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.

> 
> > page_t *x,*p;
> > for(i = 0; i < SOME_MADE_UP_NUMBER_THAT_SEEMS_GOOD;i++)
> > 	if( p = kmalloc(..)){
> > 		copyfromuser(x++,p);
> >         	dispatch_to_output(p);
> > 	    }
> > 	else {//do the rest later
> >             ...
> >           }
> 
> Please put your thinking cap on and come up with a less borked interface
> for doing that ;-)
> 
> 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?







-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com