Hi All,

Is there a max number of slabs that can be used per kernel module? I'm having a tough time finding out that kind of information, but the array 'node_zonelists' (mmzone.h) has a size of 5. I just want to avoid buffer overruns and other bad stuff.

Cheers,
Brendan

There is no arbitrary limit on the number of slabs that a kernel routine (whether or not it is a module) can use, but no computer has an infinite amount of memory either. Zones are different than slabs. Memory locations have an address and not all addresses are identical in nature. This stuff varies greatly depending on the cpu. As an example, on a typical Pentium, ZONE_DMA memory has an addresss below 16 MB and is usable for DMA transfers. There are only a very few zones. This stuff is documented in "Understanding the Linux Kernel", by Bovet and Cesati, ISBN 0-596-00565-2.

Thanks for the clarification Perderabo! I don't know why I got to thinking of slab spaces as 'zones'. I think I'll buy that book too...

I am aware that there is a limited amount of memory space, however is it not more efficient to use slabs (especially for allocations in the data path) since they result in less fragmentation and unused pages are reclaimed by the kernel anyway?

Not sure I follow you... more efficient than what? It sounds like you're still trying to compare slabs to zones. (That's like comparing TCP to ethernet.) But yes, slabs are efficient and tend to result in less fragmentation. However that "unused pages..." comment is off the mark. A freed slab tends to stay in its cache ready to be allocated again. Please read the book...I don't want to type the whole thing in. When you do, skip to page 329 "Interfacing the Slab Allocator with the Zoned Page Frame Allocator".

eh, ye tcp to ethernet... I wouldn't say I'm an expert or anything.

As regards to free pages - they may tend to stay available in the short term but they do eventually get reclaimed. I would agree it's not immediate though.

Thanks, I'll read your reference when I get my hands on the book!