[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.023 / U:35.544 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site