[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18122.46304.556919.568565@cargo.ozlabs.ibm.com>
Date: Tue, 21 Aug 2007 19:48:16 +1000
From: Paul Mackerras <paulus@...ba.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Martin Schwidefsky <schwidefsky@...ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Jan Glauber <jang@...ux.vnet.ibm.com>,
heiko.carstens@...ibm.com
Subject: Re: [accounting regression since rc1] scheduler updates
Ingo Molnar writes:
> my feeling is that it gives us generally higher-quality scheduling if we
> drive all things scheduler via virtual time. Do you agree with that?
On PowerPC at least, while we can measure virtual time, there is no
hardware facility for getting an interrupt after a certain amount of
virtual time has elapsed, but there is a facility to get an interrupt
after an elapsed real-time interval. So sched_clock() could easily
change to measure virtual time, but I don't see how to make
scheduler_tick() be driven off virtual time. It sounds like s390 is
the same.
> it seems you'd like accounting to be sensitive to 'external load' - i.e.
> you'd like an 'internal' top to show the 'real' CPU accounting, right?
>
> Wouldnt it be more consistent if a virtual box would not show any
> dependency on external load? (i.e. it would slow down all of its
> internal functionality transparently, without exposing it via /proc. The
The tools that use the data in /proc get unhappy if user time + system
time + hardirq time + softirq time + idle time + stolen time doesn't
add up to real time. The way we handle that is by making stolen time
represent the time taken away by the hypervisor (and on PowerPC with
SMT, the time taken by the other thread too).
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists