linux-kernel - Re: [PATCH] slob: reduce list scanning

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: <469B09AB.5010309@yahoo.com.au>
Date:	Mon, 16 Jul 2007 16:01:15 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Matt Mackall <mpm@...enic.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org, Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <clameter@....com>
Subject: Re: [PATCH] slob: reduce list scanning

Matt Mackall wrote:
> The version of SLOB in -mm always scans its free list from the
> beginning, which results in small allocations and free segments
> clustering at the beginning of the list over time. This causes the
> average search to scan over a large stretch at the beginning on each
> allocation.
> 
> By starting each page search where the last one left off, we evenly
> distribute the allocations and greatly shorten the average search.
> 
> Without this patch, kernel compiles on a 1.5G machine take a large
> amount of system time for list scanning. With this patch, compiles are
> within a few seconds of performance of a SLAB kernel with no notable
> change in system time.

This looks pretty nice, and performance results sound good too.
IMO this should probably be merged along with the previous
SLOB patches, because they removed the cyclic scanning to begin
with (so it may be possible that introduces a performnace
regression in some situations).

I wonder what it would take to close the performance gap further.
I still want to look at per-cpu freelists after Andrew merges
this set of patches. That may improve both cache hotness and
CPU scalability.

Actually SLOB potentially has some fundamental CPU cache hotness
advantages over the other allocators, for the same reasons as
its space advantages. It may be possible to make some workloads
faster with SLOB than with SLUB! Maybe we could remove SLAB and
SLUB then :)

-- 
SUSE Labs, Novell Inc.
-
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/