[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1296577358.5081.23.camel@mothafucka.localdomain>
Date: Tue, 01 Feb 2011 14:22:38 -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 v2 5/6] KVM-GST: adjust scheduler cpu power
On Tue, 2011-02-01 at 17:19 +0100, Peter Zijlstra wrote:
> On Tue, 2011-02-01 at 13:59 -0200, Glauber Costa wrote:
> >
> > Because that part is kvm-specific, and this is scheduler general.
> > It seemed cleaner to me to do it this way. But I can do it differently,
> > certainly.
>
> Well, any steal time clock will be hypervisor specific, but if we agree
> that anything that enables CONFIG_PARAVIRT_TIME_ACCOUNTING provides a
> u64 steal_time_clock(int cpu) function then all should be well, right?
Once the hypervisor provided the data, it can all be generic, and have
large parts of it that are generic, living in sched.c.
> The bit you have in kvm is almost that, except it assumes cpu ==
> this_cpu.
>
> You simply cannot rely on the silly tick accounting to drive any clock,
> its archaic.
Which tick accounting? In your other e-mail , you pointed that this only
runs in touch_steal_time, which is fine, will change. But all the rest
here, that is behind the hypervisor specific vs generic code has nothing
to do with ticks at all.
>
>
--
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