Hi Christoph,
On Mon, 9 Jul 2007, Pekka Enberg wrote:
> > I assume with "slab external fragmentation" you mean allocating a
> > whole page for a slab when there are not enough objects to fill the
> > whole thing thus wasting memory? We could try to combat that by
> > packing multiple variable-sized slabs within a single page. Also,
> > adding some non-power-of-two kmalloc caches might help with internal
> > fragmentation.
On Mon, 9 Jul 2007, Christoph Lameter wrote:
> Ther are already non-power-of-two kmalloc caches for 96 and 192 bytes
> sizes.
I know that, but for my setup at least, there seems to be a need for a
non-power of two cache between 512 and 1024. What I am seeing is average
allocation size for kmalloc-512 being around 270-280 which wastes total
of 10 KB of memory due to internal fragmentation. Might be a buggy caller
that can be fixed with its own cache too.
On Mon, 9 Jul 2007, Pekka Enberg wrote:
> > In any case, SLUB needs some serious tuning for smaller machines
> > before we can get rid of SLOB.
On Mon, 9 Jul 2007, Christoph Lameter wrote:
> Switch off CONFIG_SLUB_DEBUG to get memory savings.
Curious, /proc/meminfo immediately after boot shows:
SLUB (debugging enabled):
(none):~# cat /proc/meminfo
MemTotal: 30260 kB
MemFree: 22096 kB
SLUB (debugging disabled):
(none):~# cat /proc/meminfo
MemTotal: 30276 kB
MemFree: 22244 kB
SLOB:
(none):~# cat /proc/meminfo
MemTotal: 30280 kB
MemFree: 22004 kB
That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.
Nick, Matt, care to retest SLUB and SLOB for your setups?
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
