Re: [patch] kstat change to see how much Linux SMP really scale well

Andrea Arcangeli (andrea@e-mind.com)
Sat, 13 Mar 1999 13:10:07 +0100 (CET)


On 13 Mar 1999, Andi Kleen wrote:

>Nice idea. I extended it to account the lock time separately (per process

Thanks ;)

>and global). With a modified top this gives a nice overview over locking
>problems. Patch relative to your patch.

As I said to Pavel yesterday, the reason I didn't do that myself is simply
because I was worried to not break every software that uses /proc/stat. I
just thought and I perfectly agree with accounting separately the time the
kernel spent in spinning on the lock, but I was 99% sure that breaking the
/proc/stat in 2.2.3 I would had complains from everybody ;).
Breaking /proc/stat is something for 2.3.x not for 2.2.x according to me.
But note that I personally don't care to break it in 2.2.x I am an hacking
guy and I am not worried by hacking, recompiling and reinstalling all
software that are using it ;).

>I changed the lock accounting back to system, because it is really system
>time, but it is counted in the lock statistics too. To get pure (non locked)
>system overhead simply subtract the lock counter from the system time.

Agreed. This is the way it should be done, if Linus will agree to break
/proc/stat and /proc/self/status in 2.2.4 I'm fine with this way too.

>Probably only compiles on i386 because I didn't change non i386
>update_one_process callers. To catch mistakes I moved the prototype
>into sched.h though.

Another reason for not doing that was infact to not break all archs and
get a 2.2.4 that won't compile on Alpha again...

>BTW, on i386 the SMP timer interrupt does not handle lost ticks. The
>little bit screwed up statistics are probably not bad, but it disturbs
>scheduling too which may have negative effects.

Hmm how do you want to accoung lost ticks if the SMP timer interrupt won't
run in first place? The lost_ticks in the time.c code is because the bh
handler could be disabled and could be dealyed until the next timer (not
SMP) irq. The smp timer interrupt instead won't have to update things
in bh handlers so it has no way to accoung lost ticks. Note that also if
the shared timer irq handler gets really lost due a __cli() the time on
your machine will start to go slower ;). The lost_ticks is only to
avoiding lost ticks in presence of bh atomic locks.

But I see a clever and more fun way to avoid losing ticks in both the irq
handler and in the smp timer interrupt, and it's to always calc the delta
between rdtsc inside the smp timer irq. I can go into that.

Andrea Arcangeli

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/