Below, when you say "blocking", I assume you don't mean it in the
"do_block()" sense (i.e., are taken off the runqueue), but instead in
a more conventional sense; i.e., d[1-3]v0 are ahead of d4v0 in the
runqueue, and are thus "blocking" d4v0 from running?
Hmm... I can see how the "credit reset" is hurting the proportional
fairness. The problem is I can't quite see what the credit reset was
there for in the first place, so I can't tell if this is going to
screw up some other corner case that it was designed to solve. Why
not, for instance, just get rid of the conditional altogether?
Emmanuel, would you mind commenting?
-George
On Mon, Dec 8, 2008 at 6:34 AM, Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> This patch intends to accurate vcpu weighting
> for CPU intensive job.
>
> The reason of this problem is that
> vcpu round-robin queue blocks large weight vcpus
> by small weight vcpus.
>
> For example, we assume following case on 2pcpu environment.
> (with 4domains (each domain has 2vcpus))
>
> dom1 vcpu0,1 w128 credit 4
> dom2 vcpu0,1 w128 credit 4
> dom3 vcpu0,1 w256 credit 8
> dom4 vcpu0,1 w512 credit 15
>
>
> d4v0 gets 15ms credit each time.
> but if 3vcpus are blocking,(like d1v0, d2v0, d3v0)
> d4v0 credit becomes over 30msec(45msec=15x3times).
> Then d4v0 credit cleared.
> This makes d4v0 uses smaller credit than expected.
> This problem also occurs on d4v1 case.
> (blocked by d1v1, d2v1, d3v1)
>
>
> In my case, xentop shows following % for each domain.
> dom1 27
> dom2 28
> dom3 53
> dom4 88
>
> After this patch applied, each domain has following %.
> dom1 25
> dom2 25
> dom3 49
> dom4 99
>
> This patch adds condition that
> "credit clear function" should work
> when vcpu is not runnable.
>
> sched_credit.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Signed-off-by: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
>
>
> Thanks
> Atsushi SAKAI
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|