linux-kernel - Re: [RFC] i386: Remove page sized slabs for pgds and pmds

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: <20070328205055.GX8915@holomorphy.com>
Date:	Wed, 28 Mar 2007 13:50:55 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [RFC] i386: Remove page sized slabs for pgds and pmds

On Wed, Mar 28, 2007 at 01:12:56PM -0700, Christoph Lameter wrote:
> The benefit of preconstructed pgds and pmds in the i386 arch code seem to
> be debatable. The performance measurements indicate that there may be a slight
> benefit but it seems to almost vanish in the noise ratio.
> Method used (i386 1G memory):
> 1. Boot kernel
> 2. make clean
> 3. time make all

Getting the relevant results without tremendous amounts of noise from
other kernel activity needs something like lmbench's fault and fork()
microbenchmarks. Also, /proc/profile and/or oprofile results would be
useful here to get useful notions of what's happening performancewise,
in particular oprofile with L2 cache miss performance counters.

The magnitude of the degradation in the specific operations can't
really be established without these sorts of affairs. We need to know
how large a fraction of the workload is attributable to the operations
in question. Profiling would already give something of a breakdown but
it's difficult to get the numbers to add up properly or to separate
fork() from faults, so the microbenchmarks focused on the particular
operations are needed. The profiles are still needed to understand how
the time shuffled around and to either confirm or invalidate notions
regarding cache behavior.

In any event, I already know the answers because I already did all this
a number of years ago: it's all dominated by PTE caching, which was
never merged, but I carried out-of-tree for several years, so of course
it's in the noise. PMD and PTE caching are only pertinent to fork()
anyway, so the vast majority of your workload is unaffected, and it's
even more "in the noise" due to that. I can't be arsed to care about it
anymore since i386 became a target-system-only architecture for me and
am sick of the flak coming at me for my pagetable caching code anyway.
Hence this patch.

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