Adrian Bunk <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
