Messages in this thread |  | | | Date | Tue, 25 Nov 1997 17:08:06 +0000 | | From | Richard Jones <> | | Subject | Re: 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
|  |