Re: [PATCH V2] x86/split_lock: Add sysctl to control the misery mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14/10/2022 15:26, Luck, Tony wrote:
> Looks reasonable.
> 
> Are these games multi-threaded with split locks happening on multiple CPUs in parallel?
> If they are, then skipping both the 10ms delay and the serialization is needed.
> 
> But if split locks are only from one CPU at a time, then possibly it would have
> been enough to just have this mitigation skip the:
> 
> +		if (msleep_interruptible(10) > 0)
> +			return;
> 
> Maybe best not to second guess. You have left the default as "mitigation on",
> so I'm happy.
> 
> -Tony

Hi Tony, thanks for your review!

Some games are indeed multi-threaded, so as you said, I think it's
better if we skip the whole thing when the sysctl is off - a kind of
fallback to the old "warn" mode before the misery was added heh

Cheers,


Guilherme




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux