Re: fork: out of memory

Richard Jones (rjones@imcl.com)
Tue, 25 Nov 1997 17:08:06 +0000

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