[lkml]   [2006]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.19-rc5: known regressions
On Wed, 2006-11-08 at 15:11 -0800, Tim Chen wrote:
> On Wed, 2006-11-08 at 17:22 +0100, Adrian Bunk wrote:
> > There's perhaps one thing that might help us to see whether it's just a
> > benchmark effekt or a real problem:
> >
> > With Tim's CONFIG_NR_CPUS=8, NR_IRQS only increases from 224 in 2.6.18
> > to 512 in 2.6.19-rc.
> >
> > With CONFIG_NR_CPUS=255, NR_IRQS increases from 224 in 2.6.18
> > to 8416 in 2.6.19-rc.
> >
> > @Tim:
> > Can you try CONFIG_NR_CPUS=255 with both 2.6.18 and 2.6.19-rc5?
> >
> With CONFIG_NR_CPUS increased from 8 to 64:
> 2.6.18 see no change in fork time measured.
> 2.6.19-rc5 see a 138% increase in fork time.

Lmbench is broken in its fork time measurement.
It includes overhead time when it is pinning processes onto
specific cpu. The actual fork time is not affected by NR_IRQS.

Lmbench calls the following C library function to determine the
number of processors online before it pin the processes:

This function takes the same order of time to run as
fork itself. In addition, runtime of this function
increases with NR_IRQS. This resulted in the change in
time measured.

After hardcoding the number of online processors in lmbench,
the fork time measured now does not change with CONFIG_NR_CPUS
for both 2.6.18 and 2.6.19-rc5. So we can now conclude that
NR_IRQS does not affect fork. We can remove this particular
issue from the known regression.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-09 04:43    [W:0.161 / U:0.804 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site