On Thu, Dec 4, 2008 at 7:51 AM, NISHIGUCHI Naoki
<nisiguti@xxxxxxxxxxxxxx> wrote:
>> The more accurate credit scheduling and vcpu credit "balancing" seem
>> like good ideas. For the other changes, it's probably worth measuring
>> on a battery of tests to see what kinds of effects we get, especially
>> on network throughput.
>
> I didn't think about the battery and the performance.
I'm sorry, I used an uncommon definition of the word "battery"; I
should have been more careful. :-)
In this context, "a battery of tests" means "a combination of several
different kinds of tests." I meant some disk-intensive tests, some
network-intensive tests, some cpu-intensive tests, and some
combination of all three. I can run some of these, and you can make
sure that the "client" tests still work well. It would probably be
helpful to have other people volunteer to do some testing as well,
just to make sure we have our bases covered.
> I set the next-timer to 2ms in any vcpu having "boost" credits since every
> vcpu having "boost" credits need to be run equally at short intervals. If
> there are vcpus having "boost" credits and the next-timer of a vcpu is set
> to 10ms, the other vcpus will be waited during 10ms.
> At present, I am thinking that if the other vcpus don't have "boost" credits
> then we may set the next-timer to 30ms.
I see -- the current setup is good if there's only one "boosted" VM
(per cpu) at a time; but if there are two "boosted" VMs, they're back
to taking turns at 30 ms. Your 2ms patch allows several
latency-sensitive VMs to share the "low latency" boost. That makes
sense. I agree with your suggestion: we can set the timer to 2ms only
if the next waiting vcpu on the queue is also BOOST.
> I tested the video latency measurement with the "boost" time set to 10ms.
> But it regretted not to work well. As I was mentioned above, the vcpu was
> occasionally waited during 10ms.
OK, good to know.
> On my patch, "boost" time is tuneable. How about the default "boost" time is
> 30ms and if necessary, "boost" time is set? Is it acceptable?
I suspect that latency-sensitive workloads such as network, especially
network servers that do very little computation, may also benefit from
short boost times.
> In order to lengthen the "boost" time as much as possible, I will think
> about computing the length of the next-timer of the vcpu having "boost"
> credits.
If it makes things simpler, we could just stick with 10ms timeslices
when there are no waiting vcpus with BOOST priority, and 2ms if there
is BOOST priority. I don't think there's a particular need to give a
VM only (say) 8 ms instead of 10, if there are no latency-sensitive
VMs waiting.
> I'll try to revise the patch.
I suggest:
* Modify the credit scheduler directly, rather than having an extra scheduler
* Break down your changes into patches that make individual changes,
i.e (from your first post):
+ A patch to subtract credit consumed accurately
+ A patch to preserve the value of cpu credit when the vcpu is over upper bound
+ A patch to shorten cpu time per one credit
+ A patch to balance credits of each vcpu of a domain
+ A patch to introduce BOOST credit (both Xen and tool components)
+ A patch to shorten allocated time in BOOST priority if the next
vcpu on the runqueue is also at BOOST
Then we can evaluate each change individually.
Thanks for your work!
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home