[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130307212552.GB22196@amt.cnet>
Date: Thu, 7 Mar 2013 18:25:52 -0300
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Michael Wolf <mjw@...ux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
linux-kernel@...r.kernel.org, riel@...hat.com, gleb@...hat.com,
kvm@...r.kernel.org, peterz@...radead.org, glommer@...allels.com,
mingo@...hat.com, anthony@...emonkey.ws
Subject: Re: [PATCH 0/4] Alter steal-time reporting in the guest
On Thu, Mar 07, 2013 at 03:15:09PM -0600, Michael Wolf wrote:
> >
> > Makes sense?
> >
> > Not sure what the concrete way to report stolen time relative to hard
> > capping is (probably easier inside the scheduler, where run_delay is
> > calculated).
> >
> > Reporting the hard capping to the guest is a good idea (which saves the
> > user from having to measure it themselves), but better done separately
> > via new field.
>
> didnt respond to this in the previous response. I'm not sure I'm
> following you here. I thought this is what I was doing by having a
> consigned (expected steal) field add to the /proc/stat output. Are you
> looking for something else or a better naming convention?
Expected steal is not a good measure to use (because as mentioned in the
previous email there is no expected steal over a fixed period of time).
It is fine to report 'maximum percentage of underlying physical CPU'
(what percentage of the physical CPU time guest VM is allowed to make
use of).
And then steal time is relative to maximum percentage of underlying
physical CPU time allowed.
--
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