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.0703191756060.389@schroedinger.engr.sgi.com>
Date:	Mon, 19 Mar 2007 18:03:54 -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:

> > See the patch. We are only touching 2 cachelines instead of 32. So even 
> > without considering the page allocator overhead and the slab allocator 
> > overhead (which will make the situation even better) its superior.
> 
> That's not proof, it is handwaving.  I could wave right back at you and
> claim that the benefit from returning a cache-hot pte page back to the page
> allocator for reuse exceeds the benefit which you waved at me above.

No you cannot make that claim. That would mean that you have to touch 
32 pages which is inferior.

> You may well be right, but nothing is proven, afaict.

Nothing can be proven except within a rigorously defined mathematical 
system but even there we are limited by such things as Russel's paradox.

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. This patch does not change that at all for these 3 
arches. There is no doubt about the correctness of the approach here.

> > You do not think that our current way of handling ptes is okay? If we do 
> > not zero the ptes then we need to separate munmap from process shutdown.
> 
> Yep.  It's possible that process shutdown is a sufficiently common and
> costly special-case for it to be worth special-casing.

Ok great idea but what does this have to do with this patch? This patch 
simply generalizes something that has been there for ages.

> > The advantage of the quicklists is that it does not require a rework of 
> > the pte serialization.
> 
> No, these are unrelated.  We can get pte pages from the page allocator and
> zero them without touching the munmap handling.
> 
> But it's possible that if we _were_ to optimise the munmap handling as
> suggested, the end result would be superior.

Andrew, this is utter crap and unrelated to this work. The main thing here 
is to generalize something that various arches already do and to avoid the 
page struct handling collisions. You use pie-in-the-sky to argue against 
consolidating code and fixing up usage conflicts of the slab with arch 
code?
-
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/