[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1179997436.8070.3.camel@localhost>
Date: Thu, 24 May 2007 11:03:56 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: Ravikiran G Thirumalai <kiran@...lex86.org>
Cc: "Yu, Fenghua" <fenghua.yu@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>, clameter@....com,
rmk@....linux.org.uk, linux-kernel@...r.kernel.org,
heiko.carstens@...ibm.com
Subject: Re: [PATCH 1/2] Define new percpu interface for shared data --
version 3
On Wed, 2007-05-23 at 11:57 -0700, Ravikiran G Thirumalai wrote:
> > >OK, but could we please have a concise description of the impact
> > >of these changes on kernel memory footprint? Increase or decrease?
> > >And by approximately how much?
> >
> > Depending on how linker places percpu data, the patches could
> > increase or decrease percpu section size. Data from 2.6.21-rc7-mm2:
> >
> > On x86 SMP, the section size is increased from 0x7768 to 0x790c.
> > 1.3% increase.
> >
> > On X86-64 SMP, the size is decreased from 0x72d0 to 0x6540.
> > 11.8% decrease.
> >
> > On X86-64 VSMP, the size is increased from 0x72d0 to 0x8340.
> > 14.3% increase.
> >
> > On IA64 SMP, the size is decreased from 0x8370 to 0x7fc0.
> > 2.8% decrease.
>
> Has there been any measurable benefit yet due to tail padding?
> It would also be interesting to check the wastage/savings on another
> large
> cache architecture like S390 (which has a 256 byte cache line)
Current git with the patches applied and the default configuration for
s390 decreases the section size fof .data.percpu from 0x3e50 to 0x3e00.
0.5% decrease.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
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/
Powered by blists - more mailing lists