Re: [Xen-devel] [BUG] mistakenly wake in Xen's credit scheduler

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2015-10-27 at 14:11 -0600, suokun wrote:
> On Tue, Oct 27, 2015 at 3:44 AM, George Dunlap <dunlapg@xxxxxxxxx>
> wrote:
> > On Tue, Oct 27, 2015 at 5:59 AM, suokun <suokunstar@xxxxxxxxx>
> > wrote:

> Thank you for your reply. I have test credit2 this morning. The I/O
> performance is correct, however, the CPU accounting seems not
> correct.
> Here is my experiment on credit2:
> 
> VM-IO:          1-vCPU pinned to a pCPU, running netperf
> VM-CPU:      1-vCPU pinned the the same pCPU, running a while(1) loop
> The throughput of netperf is the same(941Mbps) as VM-IO runs alone.
> 
> However, when I use xl top to show the VM CPU utilization, VM-IO
> takes
> 73% of CPU time and VM-CPU takes 99% CPU time. Their sum is more than
> 100%. I doubt it is due to the CPU utilization accounting in credit2
> scheduler.
> 
Yeah, well, sorry, but even if we both (me and George) encouraged you
to try Credit2, that wasn't a great idea. :-(  In fact, you're using
pinning for this test, and Credit2 does not have pinning (yet)! :-P

That explains why utilizations are summing up to higher than 100%:
vCPUs are just not being confined to one processor.

Pinning for Credit2 is just around the corner. Let's try this again
when it will be there, ok? :-D

> > Also, do you have a patch to fix it in credit1? :-)
> > 
> 
> For the patch to my problem in credit1. I have two ideas:
> 
> 1) if the vCPU cannot migrate(e.g. pinned, CPU affinity, even only
> has
> one physical CPU), do not set the _VPF_migrating flag.
> 
Yep, that's step 1. I hadn't seen this mail, so I produced a patch
myself (see my other reply). Is it similar to your one? If you could
test it, it would be great.

Even after this is done, though, we still need to fix the fact that
Credit1 boosts vCPUs upon migrations, which looks utterly crazy to me!
I've got (drafted) patches for that too, but I want to stress test them
a bit more before submitting them officially. I'm attaching them to
this email, feel free to have a look and provide your views.

> 2) let the BOOST state can preempt with each other.
> 
Yeah, but...

> Actually I have tested both separately and they both work. But
> personally I prefer the first option because it solved the problem
> from the source.
> 
... I don't like 2) that much either. Credit1 is, by design, round
-robin within equal priority levels. There are already quite a few
hacks in that code, and breaking even that rather basic assumption
would scary an awful lot!! :-O

Thanks a lot again fro your report and your analysis.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: xen-credit1-avoid-boosting-when-migrating.patch
Description: Text Data

Attachment: xen-sched-introduce-wakeup-flags.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel