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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:01:05 EST