[lkml]   [2007]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [QUICKLIST 0/4] Arch independent quicklists V2
> On Tue, 13 Mar 2007 04:17:26 -0700 (PDT) Christoph Lameter <> wrote:
> On Tue, 13 Mar 2007, Andrew Morton wrote:
> > > On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-03-13 12:31    [W:0.163 / U:5.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site