On Thu, 2020-03-12 at 14:45 +0000, George Dunlap wrote: > > On Mar 12, 2020, at 1:44 PM, Dario Faggioli <[email protected]> > > wrote: > > > > This patch makes Credit2 more robust to events like this, whatever > > the cause is, and should hence be backported (as far as possible). > > > > Signed-off-by: Dario Faggioli <[email protected]> > > Reported-by: Glen <[email protected]> > > Reported-by: Tomas Mozes <[email protected]> > > Nit: The reported-by’s should be before the SoB (i.e., tags roughly > in time order). > Ah, right! :-(
> I think this is a good change to make the algorithm more robust, so: > > Acked-by: George Dunlap <[email protected]> > > But it seems like allowing a guest to rack up -2^63 credits is still > a bad thing, and it would be nice to have some other backstop / reset > mechanism. > I agree. FWIW, this is way it took me a while to get to the bottom of this. I was assuming it was *entirely* a Credit2 specific issue (caused by, e.g., something like I found and fixed with patch 2). When I noticed that things were not exactly like that, I also realized that we at least need to prevent --under any circumstance-- that idle vCPUs are preferred over "regular" vCPUs, and even if I did consider approaches like "compacting" the credits dynamic, I went straight for the INT_MIN approach. Considering how this thread is going, I guess we should actually push this further, and limit the "credit swing". Thanks and Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
