linux-kernel - Re: [QUICKLIST 0/4] Arch independent quicklists V2

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: <20070313042742.e35b7511.akpm@linux-foundation.org>
Date:	Tue, 13 Mar 2007 04:27:42 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-mm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [QUICKLIST 0/4] Arch independent quicklists V2

> On Tue, 13 Mar 2007 04:17:26 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:
> On Tue, 13 Mar 2007, Andrew Morton wrote:
> 
> > > On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:
> > > Page table pages have the characteristics that they are typically zero
> > > or in a known state when they are freed.
> > 
> > Well if they're zero then perhaps they should be released to the page 
> > allocator to satisfy the next __GFP_ZERO request.  If that request is 
> > for a pagetable page, we break even (except we get to remove 
> > special-case code).  If that __GFP_ZERO allocation was or some 
> > application other than for a pagetable, we win.
> 
> Nope that wont work.
> 
> 1. We need to support other states of pages other than zeroed.

What does this mean?

> 2. Prezeroing does not make much sense if a large portion of the
>    page is being used. Performance is better if the whole page 
>    is zeroed directly before use.Prezeroing only makes sense for sparse
>    allocations like the page table pages.

This is not related to the above discussion.

> > (Will require some work in the page allocator)
> > (That work will open the path to using the idle thread to prezero pages)
> 
> I already tried that 3 years ago and there was *no* benefit for usual
> users of the a page allocator. The advantage exists only if a small
> portion of the page is used. F.e. For one cacheline there was a 4x 
> improvement. See lkml archives for prezeroing.

Unsurprised.  Were non-temporal stores tried?
-
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/