lkml.org 
[lkml]   [2002]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Arch option to touch newly allocated pages
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.098 / U:6.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site