linux-kernel - Re: No, really, stop trying to delete slab until you've finished making slub perform as well

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <489738CF.7090401@linux-foundation.org>
Date:	Mon, 04 Aug 2008 12:13:51 -0500
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	KOSAKI Motohiro <m-kosaki@...es.dti.ne.jp>
CC:	Matthew Wilcox <matthew@....cx>,
	Pekka Enberg <penberg@...helsinki.fi>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
	andi@...stfloor.org, Rik van Riel <riel@...hat.com>,
	kosaki.motohiro@...fujitsu.com
Subject: Re: No, really, stop trying to delete slab until you've finished
 making slub perform as well

KOSAKI Motohiro wrote:

> When hackbench running, SLUB consume memory very largely than SLAB.
> then, SLAB often outperform SLUB in memory stavation state.
> 
> I don't know why memory comsumption different.
> Anyone know it?

Can you quantify the difference?

SLAB buffers objects in its queues. SLUB does rely more on the page allocator.
So SLAB may have its own reserves to fall back on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/