From: Mike Travis <travis@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <clameter@sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
tglx@linutronix.de, mingo@redhat.com
Subject: Re: [PATCH 05/10] x86_64: Use generic percpu
Date: Fri, 28 Dec 2007 14:05:05 -0800 [thread overview]
Message-ID: <47757311.5050503@sgi.com> (raw)
In-Reply-To: <200712281354.52453.ak@suse.de>
Andi Kleen wrote:
> On Friday 28 December 2007 01:10:51 travis@sgi.com wrote:
>> x86_64 provides an optimized way to determine the local per cpu area
>> offset through the pda and determines the base by accessing a remote
>> pda.
>
> And? The rationale for this patch seems to be incomplete.
>
> As far as I can figure out you're replacing an optimized percpu
> implementation which a dumber generic one. Which needs
> at least some description why.
The specific intent for the next wave of changes coming are to reduce
the impact of having a large NR_CPUS count on smaller systems and to
minimize memory traffic between nodes. This patchset addresses the
per_cpu data areas in preparation to cpu_alloc changes to compact the
PERCPU area, remove the various per_cpu data offset and pointer arrays,
and speed up calculating the per_cpu data offset.
Since those changes have a bigger impact it was felt that we should
prepare the groundwork before hand. It also has the benefit of
merging one more of the i386 and x86_64 headers.
> If the generic one is now as good or better than the
> specific one that might be ok, but that should be somewhere
> in the description.
I could gather some performance data, though the effect will be
larger as later changes are made.
> Also for such changes .text size comparisons before/after
> are a good idea.
x86_64-defconfig:
pre-percpu post-percpu
225 .altinstr_replacemen +0 .altinstr_replacemen
1195 .altinstructions +0 .altinstructions
716104 .bss +0 .bss
58300 .comment +0 .comment
16 .con_initcall.init +0 .con_initcall.init
415816 .data +0 .data
178688 .data.cacheline_alig +0 .data.cacheline_alig
8192 .data.init_task +0 .data.init_task
4096 .data.page_aligned +0 .data.page_aligned
27008 .data.percpu +0 .data.percpu
43904 .data.read_mostly +0 .data.read_mostly
4 .data_nosave +0 .data_nosave
5097 .exit.text +0 .exit.text
138384 .init.data +0 .init.data
133 .init.ramfs +0 .init.ramfs
3192 .init.setup +0 .init.setup
159373 .init.text +3 .init.text
2296 .initcall.init +0 .initcall.init
8 .jiffies +0 .jiffies
4512 .pci_fixup +0 .pci_fixup
1411137 .rodata +8 .rodata
35400 .smp_locks +0 .smp_locks
3629056 .text +48 .text
3368 .vdso +0 .vdso
4 .vgetcpu_mode +0 .vgetcpu_mode
218 .vsyscall_0 +0 .vsyscall_0
52 .vsyscall_1 +0 .vsyscall_1
91 .vsyscall_2 +0 .vsyscall_2
8 .vsyscall_3 +0 .vsyscall_3
54 .vsyscall_fn +0 .vsyscall_fn
80 .vsyscall_gtod_data +0 .vsyscall_gtod_data
39144 __bug_table +0 __bug_table
16320 __ex_table +0 __ex_table
44592 __ksymtab +0 __ksymtab
15200 __ksymtab_gpl +0 __ksymtab_gpl
48 __ksymtab_gpl_future +0 __ksymtab_gpl_future
87756 __ksymtab_strings +0 __ksymtab_strings
32 __ksymtab_unused_gpl +0 __ksymtab_unused_gpl
8280 __param +0 __param
7057383 Total +59 Total
next prev parent reply other threads:[~2007-12-28 22:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-28 0:10 [PATCH 00/10] percpu: Per cpu code simplification V2 travis
2007-12-28 0:10 ` [PATCH 01/10] percpu: Use a kconfig variable to signal arch specific percpu setup travis
2007-12-28 0:15 ` David Miller
2007-12-28 0:10 ` [PATCH 02/10] percpu: Move arch XX_PER_CPU_XX definitions into linux/percpu.h travis
2007-12-28 0:16 ` David Miller
2007-12-28 0:10 ` [PATCH 03/10] percpu: Make the asm-generic/percpu.h more "generic" travis
2007-12-28 0:18 ` David Miller
2007-12-28 0:10 ` [PATCH 04/10] x86_32: Use generic percpu.h travis
2007-12-28 0:10 ` [PATCH 05/10] x86_64: Use generic percpu travis
2007-12-28 12:54 ` Andi Kleen
2007-12-28 22:05 ` Mike Travis [this message]
2007-12-29 1:55 ` Andi Kleen
2007-12-31 16:19 ` Mike Travis
2008-01-02 20:58 ` Christoph Lameter
2007-12-30 14:18 ` Ingo Molnar
2007-12-31 16:21 ` Mike Travis
2007-12-31 17:10 ` Mike Travis
2008-01-01 19:17 ` Ingo Molnar
2008-01-02 21:04 ` Christoph Lameter
2008-01-02 21:33 ` Ingo Molnar
2008-01-02 20:59 ` Christoph Lameter
2008-01-02 20:55 ` Christoph Lameter
2007-12-28 0:10 ` [PATCH 06/10] s390: " travis
2007-12-28 0:10 ` [PATCH 07/10] Powerpc: Use generic per cpu travis
-- strict thread matches above, loose matches on Subject: below --
2008-01-08 21:10 [PATCH 00/10] percpu: Per cpu code simplification V4 travis
2008-01-08 21:10 ` [PATCH 05/10] x86_64: Use generic percpu travis
2008-01-08 2:11 [PATCH 00/10] percpu: Per cpu code simplification V3 travis
2008-01-08 2:11 ` [PATCH 05/10] x86_64: Use generic percpu travis
2007-12-28 0:16 [PATCH 00/10] percpu: Per cpu code simplification V2 travis
2007-12-28 0:16 ` [PATCH 05/10] x86_64: Use generic percpu travis
2007-11-28 21:09 [patch 00/10] Per cpu code simplification V2 Christoph Lameter
2007-11-28 21:09 ` [patch 05/10] x86_64: Use generic percpu Christoph Lameter
2007-11-30 11:11 ` Ingo Molnar
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=47757311.5050503@sgi.com \
--to=travis@sgi.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
/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).