All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Wolf <mjw@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Glauber Costa <glommer@parallels.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org, riel@redhat.com, gleb@redhat.com,
	kvm@vger.kernel.org, peterz@infradead.org, mingo@redhat.com,
	anthony@codemonkey.ws
Subject: Re: [PATCH 0/4] Alter steal-time reporting in the guest
Date: Thu, 07 Mar 2013 14:23:45 -0600	[thread overview]
Message-ID: <1362687825.31276.5.camel@lambeau> (raw)
In-Reply-To: <20130307031124.GB2385@drongo>

On Thu, 2013-03-07 at 14:11 +1100, Paul Mackerras wrote:
> On Wed, Mar 06, 2013 at 09:52:16PM -0300, Marcelo Tosatti wrote:
> > On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote:
> > > I looked at doing that once but was told that I was changing the
> > > interface in an unacceptable way, because now I was not reporting all of
> > > the elapsed time.  I agree it would make things simpler.
> > 
> > Pointer to that claim, please?
> 
> Back in about 2004 or 2005 or so I was looking at changing how user
> and system times were calculated (in the context of trying to find a
> better way to report resources used by a thread in an SMT processor).
> I found that utilities such as top expected the deltas in the
> /proc/stat numbers to add up to elapsed time, and would report strange
> and inconsistent results if that wasn't the case.  Unfortunately at
> this distance I don't recall the exact details.  I don't know whether
> the expectation that the deltas in the /proc/stat numbers over a
> period of time add up to the elapsed real time is documented anywhere,
> but I wouldn't be at all surprised if some programs depend on it, so
> it's better to maintain that property.

I will have to look at this again.  When looking at the cpu data where
steal time is reported there isn't a problem today.  I will have to run
it and see if there is anything incorrect with the time being reported
for the individual processes.

My real concern here was that in changing the /proc/stat interface am I
going to mess private tools that look at that information.  When I've
looked at vmstat and top they report the cpu information fine, but I may
end up creating problems for home grown scripts and tools.

  reply	other threads:[~2013-03-07 20:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 21:49 [PATCH 0/4] Alter steal-time reporting in the guest Michael Wolf
2013-02-05 21:49 ` [PATCH 1/4] Alter the amount of steal time reported by " Michael Wolf
2013-02-05 21:49 ` [PATCH 2/4] Expand the steal time msr to also contain the consigned time Michael Wolf
2013-02-06 21:14   ` Rik van Riel
2013-02-07 14:25     ` Michael Wolf
2013-02-05 21:49 ` [PATCH 3/4] Add the code to send the consigned time from the host to the guest Michael Wolf
2013-02-06 21:18   ` Rik van Riel
2013-02-07 14:26     ` Michael Wolf
2013-02-05 21:49 ` [PATCH 4/4] Add a timer to allow the separation of consigned from steal time Michael Wolf
2013-02-06 14:36   ` Glauber Costa
2013-02-06 18:07     ` Michael Wolf
2013-02-07  8:46       ` Glauber Costa
2013-02-07 14:27         ` Michael Wolf
2013-02-18 23:57   ` Marcelo Tosatti
2013-03-05 20:17     ` Michael Wolf
2013-03-06  1:35       ` Marcelo Tosatti
2013-02-18 16:43 ` [PATCH 0/4] Alter steal-time reporting in the guest Frederic Weisbecker
2013-02-19  1:11   ` Marcelo Tosatti
2013-03-05 20:22     ` Michael Wolf
2013-03-06  1:41       ` Marcelo Tosatti
2013-03-06  8:13         ` Glauber Costa
2013-03-06 16:29           ` Michael Wolf
2013-03-07  0:52             ` Marcelo Tosatti
2013-03-07  3:11               ` Paul Mackerras
2013-03-07 20:23                 ` Michael Wolf [this message]
2013-03-06 16:27         ` Michael Wolf
2013-03-07  2:30           ` Marcelo Tosatti
2013-03-07 21:09             ` Michael Wolf
2013-03-07 21:15             ` Michael Wolf
2013-03-07 21:25               ` Marcelo Tosatti
2013-03-07 22:34                 ` Michael Wolf
2013-03-08  1:54                   ` Marcelo Tosatti
2013-03-08  2:21                     ` Marcelo Tosatti
2013-03-06 13:34       ` Frederic Weisbecker
2013-03-06 16:23         ` Michael Wolf
2013-03-06 13:20     ` Frederic Weisbecker

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=1362687825.31276.5.camel@lambeau \
    --to=mjw@linux.vnet.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=fweisbec@gmail.com \
    --cc=gleb@redhat.com \
    --cc=glommer@parallels.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.