All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Yu, Fenghua" <fenghua.yu@intel.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	<linux-kernel@vger.kernel.org>, <clameter@sgi.com>
Subject: Re: [PATCH 2/2] Call percpu smp cacheline algin interface
Date: Wed, 9 May 2007 15:53:26 -0700	[thread overview]
Message-ID: <20070509155326.5e02f60d.akpm@linux-foundation.org> (raw)
In-Reply-To: <A29F7A5700A7EA4380E08C1F68C3B6D802B5F702@scsmsx411.amr.corp.intel.com>

On Wed, 9 May 2007 15:16:11 -0700
"Yu, Fenghua" <fenghua.yu@intel.com> wrote:

> 
> >hm, DEFINE_PER_CPU_SHARED_CACHELINE_ALIGNED is a bit of a mouthful.
> 
> >I wonder if we can improve things here so that we use the
> runtime-detected
> >cacheline size rather than the compile-time size.  I guess not, given
> that
> >the offsets into the percpu area are calculated at build-time.
> 
> >Did you work out how much space this change will actually save?  It
> >should be available by suitable crunching on the nm and objdump output.
> 
> Depending on how data fields are arranged by linker, the patches could
> save or waste per_cpu size. Below is data I got.
> 
> 
> Case 1: On linux-2.6.21-rc7-mm2 with defconfig build.
> Case 2: On linux-2.6.21-rc7-mm2 plus the patches in this thread with
> defconfig build.
> Case 3: On linux-2.6.21-rc7-mm2 with defconfig with VSMP=y build.
> Case 4: On linux-2.6.21-rc7-mm2 plus the patches in this thread with
> defconfig with VSMP=y build.
> 
> Please note that on x86/x86-64, per_cpu_init_tss is placed in the first
> place in per_cpu section in Case 1 and 3. And thus there is no padding
> waste for per_cpu_init_tss in Case 1 and 3.
> 
> On X86:
> Case 1: Size of per_cpu section is: 0x7768
> Case 2: Size of per_cpu section is: 0x790c
> The patches waste 0x1a4 bytes.
> 
> per_cpu__init_tss, per_cpu__irq_stat, and per_cpu__runqueues are moved
> to shared_cacheline_aligned section.
> 
> On X86-64:
> Case 1: Size of per_cpu section is: 0x72d0
> Case 2: Size of per_cpu section is: 0x6540
> The patches save 0xd90 bytes.
> 
> Case 3: Size of per_cpu section is: 0x72d0
> Case 4: Size of per_cpu section is: 0x8340
> The patches waste 0x1070 bytes. 
> 
> Shall we not use shared_cacheline_aligned section for VSMP case? The
> waste of cache eventually may offset the potential gain of alignment.
> 
> Probably need to set up a cache line size threshold: if L1 cache line
> size is bigger than a number CACHELINE_ALIGN_SHRESHOLD, don't do
> cacheline alignment.
> 
> per_cpu__init_tss and per_cpu__runqueues are moved to
> shared_cacheline_aligned section.
> 
> On ia64:
> Case 1: Size of per_cpu section is: 0x8370
> Case 2: Size of per_cpu section is: 0x7fc0
> The patches save 0x3b0 bytes.
> 
> per_cpu_ipi_operation and per_cpu_runqueues are moved to
> shared_cacheline_aligned section

erm, it's not obviosu from all this that the patches are worth proceeding
with, are they?

  reply	other threads:[~2007-05-09 22:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <33E1C72C74DBE747B7B59C1740F7443701A2F0AB@orsmsx417.amr.corp.intel.com>
2007-05-05  0:12 ` [PATCH 1/2] Define percpu smp cacheline align interface Fenghua Yu
2007-05-07 22:58   ` Fenghua Yu
2007-05-15 23:42     ` Andrew Morton
2007-05-05  0:12 ` [PATCH 0/2] Add percpu smp cacheline align section Fenghua Yu
2007-05-05 16:52   ` Christoph Lameter
2007-05-07 17:11     ` Siddha, Suresh B
2007-05-07 17:30       ` Christoph Lameter
2007-05-07 17:46         ` Siddha, Suresh B
2007-05-07 18:13           ` Yu, Fenghua
2007-05-15  0:12           ` [PATCH 2/2] Use the new percpu interface for shared data -- version 2 Fenghua Yu
     [not found]           ` <20070515001255.GA27978@linux-os.sc.intel.com>
2007-05-15  0:22             ` [PATCH 1/2] Define " Fenghua Yu
2007-05-05  0:12 ` [PATCH 2/2] Call percpu smp cacheline algin interface Fenghua Yu
2007-05-07 22:59   ` Fenghua Yu
2007-05-09 20:33     ` Andrew Morton
2007-05-09 22:16       ` Yu, Fenghua
2007-05-09 22:53         ` Andrew Morton [this message]
2007-05-09 22:56           ` Christoph Lameter
2007-05-09 23:06             ` Siddha, Suresh B
2007-05-09 23:10             ` Yu, Fenghua
2007-05-09 23:36               ` Andrew Morton

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=20070509155326.5e02f60d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    /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.