Re: [Xen-devel] Fwd: xen: credit2: credit2 can’t reach the throughput as expected

[Dario Faggioli <dfaggioli@xxxxxxxx>]

[Hey, these email are still in HTML. Please check your mail program]

On Fri, 2019-02-15 at 06:15 +0000, zheng chuan wrote:
> Hi, Dario,
>
Hi,

> Here is the xentrace in credit2 with ratelimiting 1 ms and 30ms by
> observing 1 seconds both.
> 
Ok, thanks a lot for doing this! I'm doing my own experiments, but
slower than I wanted to, as I am also a little busy with other
things... so I really appreciate your efforts. :-)

> Roughly, we can see the frequency of the context switch.
> The context switch decreases significantly when the ratelimiting
> changes from 1ms to 30ms
> linux-EBkjWt:/home # cat credit2_r_1000.log | grep __enter_scheduler
> | wc -l
> 2407
> linux-EBkjWt:/home # cat credit2_r_30000.log | grep __enter_scheduler
> | wc -l
> 714
> 
Well, sure, that's expected. It is, indeed, the intended effect of
having ratelimiting in the first place.

Now, can I ask you a favour? Can you rerun with:

 sched_credit2_migrate_resist=0

added to Xen's boot command line?

Not that I expect "miracles" (things might even get worse!), but
looking at the traces, I got curios of what kind of effect that could
have.

Also, for both the Credit1 and Credit2 cases, are you touching power
management(like with `xenpm`)?

> Since we also complement credit for sleeper vcpus to guarantee the
> fairness (also sched_latency of sleeper vcpus) once we trigger the
> reset_credit.
> it does not look like suitable for some workload such like the case
> in this issue, 
> Is that possible we try to do some punishment for the sleepers or
> complement credit in other policy to avoid too much preemption?
> 
You keep mentioning "sleepers" or "sleeping vcpus", but I don't
understand this part. A sleeping vcpu, even if it has the highest
credits, due to a reset, won't preempt any running vcpus.

It will (likely) preempt one when it wakes up, but that also happens on
Credit1  due to boosting (well, in theory... unless everyone is always
boosted, at which point things are hard to predict).

> We sacrifice throughput for the sched_latency by theory, However,
> what's interesting is that, as I said before, if I don't complement
> credit for sleepers
> or enlarge the ratelimiting, the sched_latency may not get worse
> If the vcpus runs staggeredly which spread into pCPUs when they are
> in idle at most of time due to the stable running pattern in my demo.
> 
But can we actually try to measure latency as well? Because it looks to
me that we're discussing while having only half of the picture
available.

Also, since you said you tried, can you show me (in code, I mean) what
you mean with "if I don't complement credit for sleepers", in order for
me to better understand what you mean with that?

Thanks again for you work and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel