On Wed, 2007-08-01 at 09:36 +0200, Mike Galbraith wrote:
> On Wed, 2007-08-01 at 09:30 +0200, Ingo Molnar wrote:
>
> > yeah, the posted numbers look most weird, but there's a complete lack of
> > any identification of test environment - so we'll need some more word
> > >from Roman. Perhaps this was run on some really old box that does not
> > have a high-accuracy sched_clock()? The patch below should simulate that
> > scenario on 32-bit x86.
> >
> > Ingo
> >
> > Index: linux/arch/i386/kernel/tsc.c
> > ===================================================================
> > --- linux.orig/arch/i386/kernel/tsc.c
> > +++ linux/arch/i386/kernel/tsc.c
> > @@ -110,7 +110,7 @@ unsigned long long native_sched_clock(vo
> > * very important for it to be as fast as the platform
> > * can achive it. )
> > */
> > - if (unlikely(!tsc_enabled && !tsc_unstable))
> > +// if (unlikely(!tsc_enabled && !tsc_unstable))
> > /* No locking but a rare wrong value is not a big deal: */
> > return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
> >
>
> Ah, thanks. I noticed that clocksource= went away. I'll test with
> stats, with and without jiffies resolution.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6465 root 20 0 1432 356 296 R 30 0.0 1:02.55 1 chew
6462 root 20 0 1576 216 140 R 23 0.0 0:50.29 1 massive_intr_x
6463 root 20 0 1576 216 140 R 23 0.0 0:50.23 1 massive_intr_x
6464 root 20 0 1576 216 140 R 23 0.0 0:50.28 1 massive_intr_x
Well, jiffies resolution clock did upset fairness a bit with a right at
jiffies resolution burn time, but not nearly as bad as on Roman's box,
and not in favor of the sleepers. With the longer burn time of stock
massive_intr.c (8ms burn, 1ms sleep), lower resolution clock didn't
upset it.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6511 root 20 0 1572 220 140 R 25 0.0 1:00.11 1 massive_intr
6512 root 20 0 1572 220 140 R 25 0.0 1:00.14 1 massive_intr
6514 root 20 0 1432 356 296 R 25 0.0 1:00.31 1 chew
6513 root 20 0 1572 220 140 R 24 0.0 1:00.14 1 massive_intr
-Mike
-
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/
