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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
