The search for the correct amount of split-lock misery

Posted Oct 25, 2022 6:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Parent article: The search for the correct amount of split-lock misery

Can this be a prctl setting? Perhaps a cgroup one?

The search for the correct amount of split-lock misery

Posted Oct 29, 2022 8:40 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (2 responses)

I was going to ask the same. prctl() is precisely used exactly for such things, you can decide of FPU emulation, alignment checks, speculation bypass etc. The sole reason people complain precisely is because there's no wrapper allowing the behavior to change for the life time of a program, which prctl would do just fine.

The search for the correct amount of split-lock misery

Posted Oct 29, 2022 20:06 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (1 responses)

prctl() is for things which affect the operation of the process itself. This controls whether a program making use of split locks can negatively impact the performance of the entire *system*, which puts it in a category similar to real-time priorities. As such, a privileged sysctl knob is a reasonable solution. A cgroup option could also work, and would allow access to split locks to be more precisely targeted, but it would need to require some form of elevated privilege to enable it for a regular user account.

The search for the correct amount of split-lock misery

Posted Oct 29, 2022 21:11 UTC (Sat) by joib (subscriber, #8541) [Link]

Not sure cgroups are appropriate either, since the kernel cannot isolate the impact of the split-locking only to the members of the cgroup. I guess you could make some mechanism like "at most N split locks per second for this cgroup, after that split lock usage will be throttled", though I'm not sure if it would actually be useful for any practical situation. The sysctl knob sounds much simpler and should cover most usecases.