|WikiProject Computing||(Rated Start-class)|
|It is requested that a diagram or diagrams be included in this article to improve its quality. Specific illustrations, plots or diagrams can be requested at the Graphic Lab.
For more information, refer to discussion on this page and/or the listing at Wikipedia:Requested images.
Are the fundamentals of the article correct ? 
I'm worried about all the *inaccuracy* talk on this article . I'd say most people reading this article are in search of understanding the concepts rather than diving into specific implementation details . As I understand, slab allocation pre-allocates memory for kernel objects to prevent the overhead of frequently allocating/de-allocating. The memory once allocated is not freed but the slot is freed and reserved for future allocation . . I say lets make such articles easily understandable rather than just bloating them with detail -- Leningrad (talk)
How much of this article is accurate? 
My issues with this article start at the first sentence; in contrast to the article claiming that slab allocation is to reduce internal memory fragmentation, Bonwick94 emphasizes that memory allocation needs to be fast. Furthermore, the implementation section is not only leenookcentric but also misleading; "pure" slab allocation does not imply specialist allocation of mutexen et al. It is also stated that allocation is a kernel function with kernel objects; on unix systems, save for intra-kernel allocation (which isn't visible to processes), memory allocation is done in libc, not the kernel. It doesn't get much better. All in all - I think I'm gonna slap template:cleanup-rewrite on here; if I have copious spare time soon (ha!) I may end up doing so myself. --moof (talk) 18:27, 27 November 2007 (UTC)
This article seems to tell that Linux is the only OS kernel in the world. All this stuff about bufctls, distinction between small and large slabs, and, first of all "Both the slab allocation algorithm and buddy memory allocation occur in kernel memory-allocation." are quite pointless for a general point of view. But I'm afraid the article would vanish if Linux specific things are removed. SalvoIsaja (talk) 13:01, 7 March 2008 (UTC)
For what it's worth, the original term "slab allocator" appears to come from Jeff Bonwick at Sun, who in the paper's title calls it "An object-caching kernel memory allocator". Surely it's possible to use it for other things than kernels though, and the talk of "bufctls" is imho the article's weakest moment. It doesn't even begin to explain what "bufctls" are and the sudden use of the term comes completely unexpected after reading the preceding text. 22.214.171.124 (talk) 17:02, 12 March 2009 (UTC)
I think the description of caching is way off. From what I read the cache is used to allow objects to be reused. To save time reinitializing the objects and because freeing the objects left them in a state that would allow the objects to be reallocated in a pre-initialzed state the allocated objects are given back to the OS as is and it is assumed they are initialized. See the section here http://www.ibm.com/developerworks/linux/library/l-linux-slab-allocator/ on the slab cache. 126.96.36.199 (talk) 17:08, 8 November 2011 (UTC)
More specifics 
I would like the discussion to focus on collecting knowledge. Words to be defined etc.
Slab, literally a flat thick slice, or just a chunk, is used to get a specific word for operations of memory allocation in an operating system kernel. The word was first used in this context in a description of Solaris kernel internals.
Something like that?
This intro may be better because it is more general and refers to neither Solaris nor Linux: 
Since allocation of physical memory is limited to page-sized blocks an operating system needs a more fine grained allocation mechanism which has been called "slab allocator", slab literally meaning a flat and thick slice.
SLQB implementation variant is missing 
probably very insightful for todays state of the art, but questionable for integration into wikipedia as a linked resource is this discussion on the pros and cons plus any major design aspect of the implementation flavors. http://www.gossamer-threads.com/lists/linux/kernel/1229838 --Alexander.stohr (talk) 11:58, 8 June 2010 (UTC)
- I agree. In general this article needs a serious polish and extension. There are also other variants like SLOB and SLUB, that deserve attention. I.persian (talk) 14:54, 8 June 2010 (UTC)
Non-kernel uses 
A very much used implementation outside a kernel is present in Memcached, and could provide a valuable counterpoint to the kernel-centric elements of this article. — Preceding unsigned comment added by 188.8.131.52 (talk) 13:14, 19 September 2012 (UTC)