Talk:Slab allocation

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. 83.226.76.65 (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. 129.174.97.34 (talk) 17:08, 8 November 2011 (UTC)

Yes, from what I understand the description of the cache as "cache represents a small amount of very fast memory" is completely mislead as it confuses processor caches and allocation caches, two concepts that have AFAIK nothing to do with each other 128.179.157.68 (talk) 13:14, 9 October 2014 (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.

The slab allocator manages the fine-grained memory allocation to any object size but is most efficient when dealing with objects smaller than a memory page. --d-axel (talk) 03:46, 4 August 2009 (UTC)

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 194.51.35.249 (talk) 13:14, 19 September 2012 (UTC)

Broken link to IBM article

IBM does not host it anymore it seems. 2 addresses saved it but I do not know if I should replace the link with one of them:

http://www.xuebuyuan.com/1661847.html http://blog.csdn.net/yylklshmyt20090217/article/details/5054459 — Preceding unsigned comment added by 192.124.246.246 (talk) 09:38, 7 July 2017 (UTC)

Perl external link [8] reference broken

This link numer 8 is broken. It has been archived though. Here is the earlier save of the orginal page on webarchive https://byte-me.org/perl5-porters-weekly-2012-june-17/ — Preceding unsigned comment added by 176.166.206.65 (talk) 00:36, 31 March 2022 (UTC)

Perl external link [8] reference broken (2)

Sorry for the duplicate section. I do have an account and I needed to change the first section that I made.

This link numer 8 is broken. https://byte-me.org/perl5-porters-weekly-2012-june-17/

It has been archived though. Here is the earlier save of the orginal page on webarchive : https://web.archive.org/web/20120706012459/https://byte-me.org/perl5-porters-weekly-2012-june-17/ — Preceding unsigned comment added by 176.166.206.65 (talk) 00:39, 31 March 2022 (UTC)