All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cacheline align pagevec structure
Date: Thu, 9 Sep 2004 18:41:13 -0300	[thread overview]
Message-ID: <20040909214113.GB5723@logos.cnet> (raw)
In-Reply-To: <20040909154906.57f9391b.akpm@osdl.org>

On Thu, Sep 09, 2004 at 03:49:06PM -0700, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > Right now it is 140 bytes on 64-bit and 72 bytes on 32-bit. Thats just a little bit more 
> > than a power of 2 (which will cacheline align), so shrink it to be aligned: 64 bytes on 
> > 32bit and 124bytes on 64-bit. 
> > 
> > It now occupies two cachelines most of the time instead of three. 
> > 
> > I changed nr and cold to "unsigned short" because they'll never reach 2 ^ 16.
> > 
> > I do not see a problem with changing pagevec to "15" page pointers either, 
> > Andrew, is there a special reason for that "16"? Is intentional to align
> > to 64 kbytes (IO device alignment)? I dont think that matters much because
> > of the elevator which sorts and merges requests anyway?
> > 
> > 
> > 
> > Did some reaim benchmarking on 4way PIII (32byte cacheline), with 512MB RAM:
> > 
> > #### stock 2.6.9-rc1-mm4 ####
> > 
> > Peak load Test: Maximum Jobs per Minute 4144.44 (average of 3 runs)
> > Quick Convergence Test: Maximum Jobs per Minute 4007.86 (average of 3 runs)
> > 
> > Peak load Test: Maximum Jobs per Minute 4207.48 (average of 3 runs)
> > Quick Convergence Test: Maximum Jobs per Minute 3999.28 (average of 3 runs)
> > 
> > #### shrink-pagevec #####
> > 
> > Peak load Test: Maximum Jobs per Minute 4717.88 (average of 3 runs)
> > Quick Convergence Test: Maximum Jobs per Minute 4360.59 (average of 3 runs)
> > 
> > Peak load Test: Maximum Jobs per Minute 4493.18 (average of 3 runs)
> > Quick Convergence Test: Maximum Jobs per Minute 4327.77 (average of 3 runs)
> 
> I think the patch make sense, but I'm very sceptical about the benchmarks
> ;)

Why's that? You think changing to the number of pages in the pagevec to "15" instead
"16" is the cause?

Or that the performance increase is not a direct effect of the one cacheline 
saved per pagevec instance?

Or you think such benchmark is too specific to be interpreted as a broad
vision of performance? 

:)


  reply	other threads:[~2004-09-09 23:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-09 16:39 [PATCH] cacheline align pagevec structure Marcelo Tosatti
2004-09-09 22:49 ` Andrew Morton
2004-09-09 21:41   ` Marcelo Tosatti [this message]
2004-09-09 23:20     ` Andrew Morton
2004-09-09 22:52 ` Andrew Morton
2004-09-09 23:09   ` William Lee Irwin III
2004-09-09 22:12     ` Marcelo Tosatti
2004-09-09 23:59       ` William Lee Irwin III
2004-09-09 23:22     ` Andrew Morton
2004-09-10  0:07       ` [pagevec] resize pagevec to O(lg(NR_CPUS)) William Lee Irwin III
2004-09-10  4:56         ` Nick Piggin
2004-09-10  4:59           ` Nick Piggin
2004-09-10 17:49           ` Marcelo Tosatti
2004-09-12  0:29             ` Nick Piggin
2004-09-12  5:23               ` William Lee Irwin III
2004-09-12  4:36                 ` Nick Piggin
2004-09-12  4:56             ` William Lee Irwin III
2004-09-12  4:28               ` Nick Piggin
2004-09-12  6:27                 ` William Lee Irwin III
2004-09-12  6:03                   ` Nick Piggin
2004-09-12  7:19                     ` William Lee Irwin III
2004-09-12  7:42                       ` Andrew Morton
2004-09-14  2:18                         ` William Lee Irwin III
2004-09-14  2:57                           ` Andrew Morton
2004-09-14  3:12                             ` William Lee Irwin III
2004-09-12  8:57                       ` William Lee Irwin III
2004-09-13 22:21                 ` Marcelo Tosatti
2004-09-14  1:59                   ` Nick Piggin

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=20040909214113.GB5723@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.