On Fri, Nov 4, 2011 at 2:08 PM, Lv, Hui <hui.lv@xxxxxxxxx> wrote:
> 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.
Setting the value adaptively is good, but only if it's adapting to the
right thing. :-)
For instance, adapting to number of cache misses, or to latency
requirements of guests, seems like a good idea.
But adapting to the number of scheduling events in the last period
doesn't seem very useful -- especially since our whole goal is to
change the number of scheduling events to be fewer. :-)
> 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 :).
I've heard that; thanks for doing the work.
> Also we have a set of small workloads to make quick testing.
What kinds of workloads are these?
Our performance team here is also trying to develop a lighter-weight
(i.e., easier to set up and run) benchmark for scalability /
consolidation. Hopefully once they get that up and running I can test
the scheduling characteristics as well.
Peace,
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home