Questions: Slab Allocator for Kernel Memory

Question 1

What is the primary performance advantage of keeping freed kernel objects in a pre-initialized state in the slab allocator?

• A. It allows the operating system to reclaim memory during idle periods by reusing object slots
• B. It eliminates the cost of re-initializing objects on each allocation — since freed objects are returned ready-to-use, the next allocation just grabs a pre-constructed slot
• C. It prevents memory leaks by maintaining a reference count on every allocated object
• D. It allows multiple object types to share the same slab, increasing memory utilization

Answer: (B)

Kernel objects like task_struct or inodes require expensive setup every time they're created: zeroing fields, initializing internal locks, linking pointers. Without a slab allocator, every allocation means raw memory that must be fully initialized. With object caching, freed objects are returned to their slab in constructed state — the next allocation skips all that setup and just hands back an already-initialized slot. This is analogous to a restaurant that resets table settings after each customer rather than buying new plates every time.

Question 2

A kernel developer argues: 'We should use the buddy system for all kernel allocations — it already handles fragmentation and is simpler.' What is the strongest objection to this proposal?

• A. The buddy system cannot allocate memory on modern multi-core hardware
• B. The buddy system allocates power-of-two blocks, so a 96-byte inode gets a 128-byte block (wasting 32 bytes per allocation), and it returns freed blocks as raw uninitialized memory — the slab allocator eliminates both the fragmentation and the re-initialization overhead
• C. The buddy system is too slow for allocations larger than one page
• D. The buddy system can only be used for user-space allocations, not kernel objects

Answer: (B)

The buddy system's power-of-two constraint causes internal fragmentation for small objects: a 96-byte inode rounded up to 128 bytes wastes 25% of allocated memory. More importantly, the buddy system treats every freed block as raw memory — the kernel must re-run the full initialization sequence each time. The slab allocator solves both: it pre-divides pages into exact-fit slots (no rounding) and caches objects in constructed state. The two systems work together rather than competing: buddy handles page-level allocation; slab handles fine-grained type-specific allocation.

Question 3

In a slab allocator, each object type (inode, task_struct, file descriptor) has its own dedicated cache containing slabs sized for that type.

• T. True
• F. False

Answer: True

This type-specific design is central to the slab allocator's efficiency. By creating a separate cache per object type, the allocator can size slots exactly for each type (no rounding), pre-initialize objects in the form they need, and locate free slots instantly without searching. When the kernel needs a new inode, it asks the inode cache — which hands back an already-sized, pre-constructed slot with no search, no splitting, no initialization.

Question 4

The slab allocator replaces the buddy system, taking over page-level memory management from the Linux kernel.

• T. True
• F. False

Answer: False

The slab allocator and the buddy system work together at different levels of granularity. The buddy system handles coarse-grained page allocation — it gives the slab allocator the pages it needs for new slabs. The slab allocator then sub-divides those pages into fine-grained, type-specific object slots. Neither replaces the other: remove the buddy system and the slab allocator has no source of pages; remove the slab allocator and the buddy system must handle millions of small object allocations inefficiently.

Question 5

Why does the slab allocator reduce internal memory fragmentation compared to the buddy system, and how does object caching further improve performance beyond just fragmentation reduction?

Model answer: The buddy system allocates power-of-two blocks, so small objects are rounded up: a 96-byte inode gets a 128-byte block, wasting 32 bytes per object — internal fragmentation. The slab allocator pre-divides pages into slots exactly sized for one object type, so a 96-byte inode occupies exactly 96 bytes with no rounding waste. Object caching adds a second improvement that fragmentation reduction alone doesn't provide: instead of returning freed memory to a raw pool (requiring full re-initialization next time), the slab keeps freed objects in constructed state. Since many kernel objects require expensive setup (zeroing fields, initializing spinlocks, setting up internal pointers), avoiding redundant initialization on each allocation dramatically reduces allocation latency beyond what merely eliminating fragmentation would achieve.

The two benefits are independent: you could eliminate fragmentation with a non-power-of-two allocator without caching pre-initialized objects, and you could cache objects without eliminating fragmentation. The slab allocator does both simultaneously because type-specific caches naturally enable type-specific object sizes.