Core scheduling lands in 5.14

It seems to me this feature could be useful for a subset of processes on any desktop system, because while most processes on a desktop shouldn't be affected by this stuff, web browsers in particular routinely run untrusted code. They could use this to assign distinct cookies to processes handling mutually untrusted code from distinct security domains (whatever those might be in the present-day state of the web). If you wanted to minimize performance impact, it seems to me you could allow a process to have *no* cookie (perhaps by having all processes share the same cookie until explicitly assigned), and prohibit uncookied processes from running on the same core as any processes with cookies. The only intrinsic, necessary performance impact then would be to stop most things sharing a core with a web browser running potentially untrusted code, which is exactly what you want in this case.