[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1362687825.31276.5.camel@lambeau>
Date: Thu, 07 Mar 2013 14:23:45 -0600
From: Michael Wolf <mjw@...ux.vnet.ibm.com>
To: Paul Mackerras <paulus@...ba.org>
Cc: Marcelo Tosatti <mtosatti@...hat.com>,
Glauber Costa <glommer@...allels.com>,
Frederic Weisbecker <fweisbec@...il.com>,
linux-kernel@...r.kernel.org, riel@...hat.com, gleb@...hat.com,
kvm@...r.kernel.org, peterz@...radead.org, mingo@...hat.com,
anthony@...emonkey.ws
Subject: Re: [PATCH 0/4] Alter steal-time reporting in the guest
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.
--
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