>
> Hey Hui, Sorry for the delay in response -- FYI I'm at the XenSummit Korea
> now, and I'll be on holiday next week.
>
Have a good trip in Korea and the following holiday! And Say Hi to everyone
there。 ：）
> I'm attaching a prototype minimum timeslice patch that I threw together last
> week. It currently hangs during boot, but it will give you the idea of what I
> was thinking of.
>
> Hui, can you let me know what you think of the idea, and if you find it
> interesting, could you try to fix it up, and test it? Testing it with bigger
> values
> like 5ms would be really interesting.
I agree that this idea seems more natural and proper, if it can solve the two
problems that I addressed above. We need data to prove/disprove it.
As you mentioned that, this method is supposed to have the similar result as
the patch I sent, when setting 10ms as the delay value in the excessive
condition.
So that, an idea came to me that may enforce your proposal,
1. we still count the scheduling number during each period (for example 10ms)
2. This scheduling number is used to adaptively decide the delay value.
For example, if scheduling number is very excessive, we can set longer delay
time, such as 5ms or 10ms. Or if the scheduling number is small, we can set
small delay time, such as 1ms, 500us or even zero. In this way, the delay value
is decided adaptively.
I think It can solve the possible problems that I addressed above.
George, how do you think this?
I'd like to try this and see the result. May also to compare the results
between different solutions. As you know, SPECvirt workloads is too complex
that I need some time to produce this :).
Also we have a set of small workloads to make quick testing.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home