On 02/01/2011 05:57 PM, Glauber Costa wrote:
On Sun, 2011-01-30 at 16:04 +0200, Avi Kivity wrote: > On 01/28/2011 09:52 PM, Glauber Costa wrote: > > This patch accounts steal time time in kernel/sched. > > I kept it from last proposal, because I still see advantages > > in it: Doing it here will give us easier access from scheduler > > variables such as the cpu rq. The next patch shows an example of > > usage for it. > > > > Since functions like account_idle_time() can be called from > > multiple places, not only account_process_tick(), steal time > > grabbing is repeated in each account function separatedely. > > > > I accept that steal time is worthwhile, but do you have some way to > demonstrate that the implementation actually works and is beneficial? > > Perhaps run two cpu-bound compute processes on one vcpu, overcommit that > vcpu, and see what happens to the processing rate with and without steal > time accounting. I'd expect a fairer response with steal time accounting. Avi, There are two things here: One of them, which is solely the accounting of steal time, (patches 1 to 4) has absolutely nothing to do with what you said. Its sole purpose is to provide the user with information about "why is my process slow if I am using 100 % of my cpu?")
Right. Like irq and softirq time, we need to report this to the user, as it's potentially much higher.
The last patch is the only one that actually tries to rebalance cpus according to steal time information. For that, I do have some experiments I did here to see if it is working, will try to provide more precise data in the next submission.
Thanks. -- error compiling committee.c: too many arguments to function -- 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
