From: ebiederm@xmission.com (Eric W. Biederman)
To: Adrian Bunk <bunk@stusta.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
linux-kernel@vger.kernel.org, ak@suse.de, discuss@x86-64.org
Subject: Re: 2.6.19-rc1: x86_64 slowdown in lmbench's fork
Date: Fri, 03 Nov 2006 02:08:42 -0700 [thread overview]
Message-ID: <m1bqnozylh.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20061103021145.GD13381@stusta.de> (Adrian Bunk's message of "Fri, 3 Nov 2006 03:11:45 +0100")
Adrian Bunk <bunk@stusta.de> writes:
> On Thu, Nov 02, 2006 at 10:34:13AM -0800, Tim Chen wrote:
>> On Thu, 2006-11-02 at 11:33 -0700, Eric W. Biederman wrote:
>>
>> > My only partial guess is that it might be worth adding the per cpu
>> > variables my patch adds without any of the corresponding code changes.
>> > And see if adding variables to the per cpu area is what is causing the
>> > change.
>> >
>> > The two tests I can see in this line are:
>> > - to add the percpu vector_irq variable.
>> > - to increase NR_IRQs.
>>
>> Increasing the NR_IRQs resulted in the regression.
>>...
>
> What's your CONFIG_NR_CPUS setting that you are seeing such a big
> regression?
Also could we see the section of System.map that deals with
per cpu variables.
I believe there are some counters for processes and the like
just below kstat whose size increase is causing you real
problems.
Ugh. I just looked at include/linux/kernel_stat.h
kstat has the per cpu irq counters and all of the cpu process
time accounting so it is quite likely that we are going to be
touching this structure plus the run queues and the process counts
during a fork. All of which are now potentially much more spread out.
Also has anyone else reproduce this problem yet?
I don't doubt that it exists but having a few more data points or
eyeballs on the problem couldn't hurt.
Eric
next prev parent reply other threads:[~2006-11-03 9:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 16:44 2.6.19-rc1: Slowdown " Tim Chen
2006-11-02 18:33 ` Eric W. Biederman
2006-11-02 18:34 ` Tim Chen
2006-11-03 2:11 ` 2.6.19-rc1: x86_64 slowdown " Adrian Bunk
2006-11-03 9:08 ` Eric W. Biederman [this message]
2006-11-03 16:10 ` Tim Chen
2006-11-03 17:35 ` Eric W. Biederman
2006-11-03 17:47 ` Andi Kleen
2006-11-03 18:18 ` Eric W. Biederman
2006-11-03 18:39 ` Andi Kleen
2006-11-03 20:25 ` Tim Chen
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=m1bqnozylh.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=bunk@stusta.de \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tim.c.chen@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®