> On Mar 19, 2020, at 12:12 AM, Dario Faggioli <dfaggi...@suse.com> wrote:
>
> There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset
> credit on reset condition"). In fact, the aim of that commit was to
> make sure that we do not perform too many credit reset operations
> (which are not super cheap, and in an hot-path). But the check used
> to determine whether a reset is necessary was the wrong one.
>
> In fact, knowing just that some vCPUs have been skipped, while
> traversing the runqueue (in runq_candidate()), is not enough. We
> need to check explicitly whether the first vCPU in the runqueue
> has a negative amount of credit.
Oh, so if the top of the runqueue has negative credit, but it’s not chosen,
then the one we *do* run has even lower credit. Still not quite sure how that
leads to a situation where credit resets don’t happen for long periods of time.
But anyway...
>
> Since a trace record is changed, this patch updates xentrace format file
> and xenalyze as well
>
> This should be backported.
>
> Signed-off-by: Dario Faggioli <dfaggi...@suse.com>
Acked-by: George Dunlap <george.dun...@citrix.com>
