linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [QUICKLIST 0/4] Arch independent quicklists V2
Date: Tue, 13 Mar 2007 04:17:26 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0703130413080.5720@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070313005334.853559ca.akpm@linux-foundation.org>

On Tue, 13 Mar 2007, Andrew Morton wrote:

> > On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <clameter@sgi.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.

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.

> (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.



  parent reply	other threads:[~2007-03-13 11:17 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13  7:13 [QUICKLIST 0/4] Arch independent quicklists V2 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 1/4] Generic quicklist implementation Christoph Lameter
2007-03-13  9:05   ` Paul Mundt
2007-03-15 20:51     ` Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 2/4] Quicklist support for i386 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 3/4] Quicklist support for x86_64 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 4/4] Quicklist support for sparc64 Christoph Lameter
2007-03-13  8:53 ` [QUICKLIST 0/4] Arch independent quicklists V2 Andrew Morton
2007-03-13  8:03   ` Nick Piggin
2007-03-13 11:52     ` Andrew Morton
2007-03-13 11:06       ` Nick Piggin
2007-03-13 12:15         ` Andrew Morton
2007-03-13 11:20           ` Christoph Lameter
2007-03-13 12:30             ` Andrew Morton
2007-03-15 20:23               ` Christoph Lameter
2007-03-13 11:30           ` Nick Piggin
2007-03-13 12:47             ` Andrew Morton
2007-03-13 12:01               ` Nick Piggin
2007-03-13 13:11                 ` Andrew Morton
2007-03-13 12:18                   ` Nick Piggin
2007-03-13 17:30                 ` Jeremy Fitzhardinge
2007-03-13 20:03                   ` Matt Mackall
2007-03-13 20:17                     ` Jeremy Fitzhardinge
2007-03-13 20:21                       ` Matt Mackall
2007-03-13 21:07                         ` David Miller
2007-03-13 21:14                           ` Matt Mackall
2007-03-13 21:36                             ` Jeremy Fitzhardinge
2007-03-13 21:46                               ` Peter Chubb
2007-03-13 21:48                             ` David Miller
2007-03-14  1:12               ` William Lee Irwin III
2007-03-15 23:12                 ` William Lee Irwin III
2007-03-13 23:58       ` Paul Mackerras
2007-03-13 11:17   ` Christoph Lameter [this message]
2007-03-13 12:27     ` Andrew Morton
2007-03-15 20:28       ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0703130413080.5720@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).