linux-kernel - Re: [PATCH 04/20] Convert gfp_zone() to use a table of precalculated values

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: <200902240241.48575.nickpiggin@yahoo.com.au>
Date:	Tue, 24 Feb 2009 02:41:47 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Mel Gorman <mel@....ul.ie>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lin Ming <ming.m.lin@...el.com>,
	Zhang Yanmin <yanmin_zhang@...ux.intel.com>
Subject: Re: [PATCH 04/20] Convert gfp_zone() to use a table of precalculated values

On Tuesday 24 February 2009 02:23:52 Christoph Lameter wrote:
> On Sun, 22 Feb 2009, Mel Gorman wrote:
> > Every page allocation uses gfp_zone() to calcuate what the highest zone
> > allowed by a combination of GFP flags is. This is a large number of
> > branches to have in a fast path. This patch replaces the branches with a
> > lookup table that is calculated at boot-time and stored in the
> > read-mostly section so it can be shared. This requires __GFP_MOVABLE to
> > be redefined but it's debatable as to whether it should be considered a
> > zone modifier or not.
>
> Are you sure that this is a benefit? Jumps are forward and pretty short
> and the compiler is optimizing a branch away in the current code.

Pretty easy to mispredict there, though, especially as you can tend
to get allocations interleaved between kernel and movable (or simply
if the branch predictor is cold there are a lot of branches on x86-64).

I would be interested to know if there is a measured improvement. It
adds an extra dcache line to the footprint, but OTOH the instructions
you quote is more than one icache line, and presumably Mel's code will
be a lot shorter.

>
> 0xffffffff8027bde8 <try_to_free_pages+95>:      mov    %esi,-0x58(%rbp)

--
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/