Re: [PATCH 6.0.y / 6.1.y] x86/split_lock: Add sysctl to control the misery mode

[Sean Christopherson]

+Stas

On Mon, Dec 19, 2022, Guilherme G. Piccoli wrote:
> On 19/12/2022 07:59, Peter Zijlstra wrote:
> > On Mon, Dec 19, 2022 at 11:17:39AM +0100, Greg KH wrote:
> > 
> >> What specific programs have this problem and what are the exact results
> >> of it?
> > 
> > IIRC it was God of War (2018) that triggered this initially. But it's
> > possible more games were found to tickle this specific thing. Since it's
> > binary only gunk that is unlikely to ever get fixed we need something to
> > allow for it.
> > 
> > (slow motion Kratos yelling B...o...y...)
> > 
> >> Also, this is really a new feature and not really a "fix", but one could
> >> argue a lot that this is a "resolve a performance problem" if you want
> >> to and have the numbers to back it up  {hint}
> > 
> > Right, there were some, they should indeed have been included.
> 
> Thanks Peter, that's exactly it - the current report is linked on commit
> message.
> 
> About performance numbers, the only "numbers" I have is: game is
> unplayable, according to the report "When I launch God of War through
> Steam or Lutris I get around 25 fps, on lowest settings and at 10%
> resolution scaling", FPS for for games is double of that usually.
> 
> I understand this is not a regular fix in which something is completely
> broken, but it does fix a behavior introduced on kernel that prevent
> some userspace binaries to properly run, in practice. Ofc some will
> argue that we already have the kernel parameter, but it's different -
> requires reboot and bootloader understanding.
> 
> If 6.0.y is too much, I'd ask we have it at least for 6.1, which is
> long-term, that will help a lot of people for sure.
> Thanks,

Resurrecting this thread with a concrete use case.

dosemu2, which uses KVM to accelerate DOS emulation (stating the obvious), ran
into a problem where the hardcoded (prior to this patch) behavior will effectively
hang userspace if the 10ms sleep is interrupted, e.g. by a periodic SIGALRM[*].

Alternatively, we could try to figure out a way to ensure forward progress without
letting userpace run an end-around on the enforced misery, but backporting this
patch to stable kernels seems easier.

Stas, do you happen to know what the oldest stable kernel your users use, i.e.
how far back this backport would need to go?

[*] https://github.com/dosemu2/dosemu2/issues/1968#issuecomment-1486709361