[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 ...


Richard Jones Tel: +44 171 460 6141 Fax: .. 4461
ABLE INmEDIA Ltd. 262a Fulham Rd. London SW10 9EL. "you'll write in
PGP: 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.164 / U:3.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site