lkml.org 
[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: the new VMt
On Mon, Sep 25, 2000 at 07:24:53PM +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, Sep 25, 2000 at 12:13:15PM -0600, yodaiken@fsmlabs.com wrote:
>
> > > Definitely not. GFP_ATOMIC is reserved for things that really can't
> > > swap or schedule right now. Use GFP_ATOMIC indiscriminately and you'll
> > > have to increase the number of atomic-allocatable pages.
> >
> > Process 1,2 and 3 all start allocating 20 pages
> > process 1 stalls after allocating 19
> > some memory is freed and process 2 runs and stall after allocating 19
> > some memory is free and process 3 runs and stalls after allocating 19
> >
> > now 57 pages are locked up in non-swapable kernel space and the system deadlocks OOM.
>
> Or go the beancounter route: process 1 asks "can I pin 20 pages", gets
> told "yes", and goes allocating them, blocking as necessary until it

So you have a "pre-allocation allocator"? Leads to interesting and hard to detect
bugs with old code that does not pre-allocate or with code that incorrectly pre-allocates
or that blocks on something unrelated

preallocte 20 pages
get first
ask for an inode -- block waiting for an inode


or
preallocate 20 pages
if(checkuserpath())return -ENOWAY; /* stranding my pre-allocate */
else get them pages


What's nice about these is they don't cause errors on test and seem more
difficult to spot than looking for cases where allocated memory gets stranded.
Doesn't the alloc_vec method seem simpler to you?

> gets them. Process 2 asks "can *I* pin 20 pages" and the answer is
> either "not right now", in which case it waits for process 1 to
> release its reservation, or "no, you've exceeded your user quota" in

Or for someone else to free more pages ...

> which case it fails with ENOMEM. (That latter case can protect us
> against a lot of DoS attacks from local users.)

I like ENOMEM anyways.

>
> The same accounting really needs to be done for page tables, as that
> represents one of the biggest sources of unaccounted, unswappable
> pages which user processes can cause to be created right now.



--
---------------------------------------------------------
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
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.612 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site