[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1295985756.15920.33.camel@mothafucka.localdomain>
Date: Tue, 25 Jan 2011 18:02:36 -0200
From: Glauber Costa <glommer@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
aliguori@...ibm.com, Rik van Riel <riel@...hat.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
Avi Kivity <avi@...hat.com>
Subject: Re: [PATCH 16/16] KVM-GST: adjust scheduler cpu power
On Mon, 2011-01-24 at 20:51 +0100, Peter Zijlstra wrote:
> On Mon, 2011-01-24 at 16:51 -0200, Glauber Costa wrote:
> > > I would really much rather see you change update_rq_clock_task() and
> > > subtract your ns resolution steal time from our wall-time,
> > > update_rq_clock_task() already updates the cpu_power relative to the
> > > remaining time available.
> >
> > But then we get into the problems we already discussed in previous
> > submissions, which is, we don't really want to alter any notion of
> > wallclock time. Could you list any more concrete advantages of the
> > specific way you proposed?
>
> clock_task is the time spend on the task, by not taking steal time into
> account all steal time is accounted as service to whatever task was
> current when the vcpu wasn't running.
>
> It doesn't change wall-time in the sense of gtod, only the service time
> to tasks.
I fail to see how does clock_task influence cpu power.
If we also have to touch clock_task for better accounting of other
stuff, it is a separate story.
But for cpu_power, I really fail. Please enlighten me.
I did have slightly better results accounting the whole steal time
period away from total_"ticks"(*) than just with units.
* Please note again that ticks here is just a (bad, I admit) name.
This is not tick accounting, is just an estimate of how much useful work
your cpu did.
--
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