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.
For instance, it happened in the midst of compiling gimp, but I simply
restarted that make and it ran to completion. Perhaps some "coalescing"
is done to refragment pages, since all that compile stuff could
easily fragment the memory. If not, then the cannot fork: message would
get worse over time, which is something I have not yet observed.
> BTW, right now, there are 46 processes on my machine. Neither one of
> them use more than 64 fd's. Even such a bloat like Netscape uses only
> 26. To allocate all needed files_struct, kernel used more than 200KB
> of nonpageable memory which is mostly (95%) unused!!!
Your ideas seem OK, but I'm not anywhere close to being a
kernel hacker. :( But such an observation, if true, really needs to
be fixed asap. Question, though: if files_struct is using non-
pageable memory, it is using kernel (ring 0) memory, correct, which
is contiguous by definition?
> Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
------------------------------------------------------------------------
David E. Fox Tax Thanks for letting me
dfox@belvdere.vip.best.com the change magnetic patterns
root@belvedere.sbay.org churches on your hard disk.
-----------------------------------------------------------------------