linux-kernel - Re: [QUICKLIST 1/5] Quicklists for page table pages V3

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: <Pine.LNX.4.64.0703201236110.8729@schroedinger.engr.sgi.com>
Date:	Tue, 20 Mar 2007 12:41:44 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-mm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [QUICKLIST 1/5] Quicklists for page table pages V3

On Mon, 19 Mar 2007, Andrew Morton wrote:

> Yes, a common quicklist implementation is good.  But no quicklist
> implementation at all is better.  You say that will be slower, and you may
> well be right, but I say let's demonstrate that (please) rather than
> speculating.

There are at least 3 arches already using this scheme there is no 
speculation here. The slab use in i386 is for exactly the same purpose. 
There is nothing new here. It consolidates code and fixes the page struct 
use conflict between slab and arch code. The conflict is the main reason 
why I want this. That way I will not have the special casing in SLUB and 
we can make SLAB support debugging for all slab caches.

> > Its obvious that this is right. And there has been significant work 
> > invested into retaining page table pages on i386, sparc64 and ia64 for 
> > exactly the specified.
> 
> I believe that work predated per-cpu-pages.

Lots of arch code depends on page table pages being in a known state for 
reuse this is nothing new. 

> > Ok great idea but what does this have to do with this patch? This patch 
> > simply generalizes something that has been there for ages.
> 
> It has a lot to do with this patch.
> 
> If we decide that it is useful to optimise the full-mm teardown case then
> we will need to zero these pages when we start to use them so we might as
> well get them straight from the page allocator.  Hence this patch goes into
> the bitbucket.

If you decide to optimise the full-mm teardown then you will have to 
rework more than half of the arch handling of page table pages since they 
all rely on pages being zero on return.

> It is not pie-in-the-sky to ask "is this code still useful?".

Yes it is if its a funky idea without code or any data to support a major 
change in the way we handle page table pages. And this falls into that 
category.

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