lkml.org 
[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fork: out of memory
David E. Fox wrote:
>
> > 1) Slab allocator.
>
> OK, what is a slab? I figure it is a chunk of RAM that is used to
> serve pages from.
>
> > It needs 8!!! contiguos pages to allocate one files_struct in
> > files_cachep cache. Well, other 6 (or 5?) allocations will be fast
>
> Ouch. Well, one would think that would be a simple thing; even on a
> heavily(?) used system it's conceivable that there would be 8 pages
> in a row that could be used. If not, memory must be rather heavily
> fragmented. On the other hand, since it's happened to me a couple
> of times now, I wonder how so, and also whether or not the memory
> "coalesces" over time, since I could be in an app and not have it
> go off, then close the app and have it go off, then go into something
> slse, and bingo - it goes off again, another cannot fork: error.

I must be missing a big point here ... why is it not
possible to either (a) turn on paging in the kernel
so that non-contiguous pages can be easily made to look
contiguous to kernel code, or (b) when you can't find
8 contiguous pages, pick the first free page and swap
the data in the next 7 adjacent pages with other free
pages in memory. Method (b) could construct any number of
contiguous free pages atomically with the only penalty
being some chunky memcpy's ...

Rich.

--
Richard Jones rjones@imcl.com Tel: +44 171 460 6141 Fax: .. 4461
ABLE INmEDIA Ltd. 262a Fulham Rd. London SW10 9EL. "you'll write in
PGP: www.four11.com telegraphic, or you won't write at all" [Céline]
To send me email, please leave this line in your reply: RJ-AUTH-DHQJENBA

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