On 2018-09-15 3:04 a.m., Marek Olšák wrote: > On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer <mic...@daenzer.net> wrote: >> On 2018-09-13 8:56 p.m., Marek Olšák wrote: >> >>> + * What happens if a driver is unloaded and the app creates a thread? >> >> I suppose the child process will likely crash, because the memory >> address where util_set_full_cpu_affinity was located will either be >> unmapped or have random other contents? >> >> At least in theory, there could also be an issue where the application >> might have set its own thread affinity before calling fork, which would >> be clobbered by util_set_full_cpu_affinity in the child process. >> >> >> Last but not least, this doesn't solve the issue of apps such as >> blender, which spawn their own worker threads after initializing OpenGL >> (possibly not themselves directly, but via the toolkit or another >> library; e.g. GTK+4 uses OpenGL by default), inheriting the thread affinity. >> >> >> Due to these issues, setting the thread affinity needs to be disabled by >> default, and only white-listed for applications where it's known safe >> and beneficial. This sucks, but I'm afraid that's the reality until >> there's better API available which allows solving these issues. > > We don't have the bandwidth to maintain whitelists. This will either > have to be always on or always off. > > On the positive side, only Ryzens with multiple CCXs get all the > benefits and disadvantages.
In other words, only people who spent relatively large amounts of money for relatively high-end CPUs will be affected (I'm sure they'll be glad to know that "common people" aren't affected. ;). Affected applications will see their performance decreased by a factor of 2-8 (the number of CCXs in the CPU). OTOH, only a relatively small number of games will get a significant benefit from the thread affinity, and the benefit will be smaller than a factor of 2. This cannot justify risking a performance drop of up to a factor of 8, no matter how small the risk. Therefore, the appropriate mechanism is a whitelist. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
