public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Jan Glauber <jang@linux.vnet.ibm.com>,
	heiko.carstens@de.ibm.com, Paul Mackerras <paulus@samba.org>
Subject: Re: [accounting regression since rc1]  scheduler updates
Date: Tue, 21 Aug 2007 13:58:45 +0200	[thread overview]
Message-ID: <1187697526.24279.20.camel@localhost> (raw)
In-Reply-To: <20070821113611.GB2390@elte.hu>

On Tue, 2007-08-21 at 13:36 +0200, Ingo Molnar wrote:
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> 
> > > 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 only way to observe that would be the TOD interfaces: 
> > > gettimeofday and real-time clock driven POSIX timers. Even 
> > > timer_list could be driven via virtual time - although that would 
> > > probably break user expectations, right?) Or would 
> > > accounting-in-virtual-time break user expectations too? (most of the 
> > > other hypervisors let guests account in virtual time.
> > 
> > No, imho it is less consistent if the virtual box shows virtual time. 
> > If you look at the top output as a user and it shows that some process 
> > used x% of cpu what does it tell you? [...]
> 
> it tells me something really important: that the virtual box's scheduler 
> gave this task as much CPU time as it could.

So? As far as accounting is concerned the user doesn't care one bit what
the scheduler decided. The user cares how much cpu was used. If you want
to know how much of the cputime available to the virtual box was used
for a process you just have to add/subtract the steal time. Your have
the complete picture what happened. You cannot get the complete picture
if you have do process accounting based on the TOD clock, you never know
how much cpu was actually spent for a process.

> > [...] With virtual cpus next to nothing, you have to normalize the 
> > numbers with the %steal while the process was running. But even then 
> > it still is not a good number because the %steal changes while a 
> > process is running. The only good solution is to use virtual time for 
> > all cputime values.
> 
> the steal percentage is really a concept one step higher in the 
> scheduling hierarchy. You should be running top (or an equivalent tool) 
> in the _hypervisor_ context if you want to know about how much time each 
> virtual box gets. 'mixing' that information with the 'internal' task 
> statistics of the virtual box is less consistent IMO and leads to the 
> loss of information. (with the 'mixing' method there's no way to tell 
> whether a task got all CPU time it asked for - and _that_ is which an 
> admin is interested in just as much as the time allocation between 
> virtual boxes.)

Not really. If I look at a process I want to know how much cpu it used.
Not virtual but real cpu. And we learned this the hard way, trying to do
accounting with numbers that have to get normalized by numbers from the
hypervisor is just plain broken.

> so in say KVM you determine the steal percentage by looking at 'top' 
> output in the hypervisor context. (or looking at steal% in the internal 
> top output) Looking at 'top' in the guest tells you everything internal 
> to that guest, without mixing external scheduling information into it.

The information about accounting numbers that are internal to the guest
is 99.99% useless. You always have to take the external scheduling into
account. We choose to do the accounting in a way that does not require
additional steps to get to useful numbers.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.



  reply	other threads:[~2007-08-21 11:55 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12 16:32 [git pull request] scheduler updates Ingo Molnar
2007-08-14  8:37 ` [accounting regression since rc1] " Christian Borntraeger
2007-08-16  8:17   ` [PATCH][RFC] Re: accounting regression since rc1 Christian Borntraeger
2007-08-20 15:45   ` [accounting regression since rc1] scheduler updates Ingo Molnar
2007-08-20 17:03     ` Martin Schwidefsky
2007-08-20 18:08       ` Ingo Molnar
2007-08-20 18:33         ` Martin Schwidefsky
2007-08-20 19:00           ` Balbir Singh
2007-08-20 19:05           ` Ingo Molnar
2007-08-21  7:20             ` Christian Borntraeger
2007-08-20 19:12           ` Ingo Molnar
2007-08-21  7:00           ` Christian Borntraeger
2007-08-21  9:18             ` Martin Schwidefsky
2007-08-20 23:07         ` Paul Mackerras
2007-08-21  2:18         ` Andi Kleen
2007-08-21  7:09           ` Ingo Molnar
2007-08-21 10:07             ` Andi Kleen
2007-08-21 10:20               ` Ingo Molnar
2007-08-21 11:15                 ` Andi Kleen
2007-08-21 11:20                   ` Ingo Molnar
2007-08-21  8:17     ` Christian Borntraeger
2007-08-21  8:42       ` Ingo Molnar
2007-08-21  9:11         ` Martin Schwidefsky
2007-08-21  9:34           ` Ingo Molnar
2007-08-21  9:48             ` Paul Mackerras
2007-08-21 10:38             ` Martin Schwidefsky
2007-08-21 11:36               ` Ingo Molnar
2007-08-21 11:58                 ` Martin Schwidefsky [this message]
2007-08-21 10:39             ` Christian Borntraeger
2007-08-21 10:43             ` Christian Borntraeger
2007-08-21 11:15               ` Ingo Molnar
2007-08-21 11:24                 ` Christian Borntraeger
2007-08-21 11:30                   ` Ingo Molnar
2007-08-21 11:58                     ` Christian Borntraeger
2007-08-21 12:21                       ` Ingo Molnar
2007-08-21 12:57                         ` Martin Schwidefsky
2007-08-21 11:25       ` Ingo Molnar
2007-08-22  7:50         ` Christian Borntraeger
2007-08-22  7:59           ` Ingo Molnar
     [not found] ` <200708141032.47235.borntraeger@de.ibm.com>
     [not found]   ` <alpine.LFD.0.999.0708140835240.30176@woody.linux-foundation.org>
2007-08-14 18:19     ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1187697526.24279.20.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jang@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox