[Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

Gustaw Smolarczyk wielkiegie at gmail.com
Sun Oct 28 10:27:58 UTC 2018

pon., 17 wrz 2018 o 18:24 Michel Dänzer <michel at daenzer.net> napisał(a):
> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
> > On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer <michel at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


What was the conclusion of this discussion? I don't see any
whitelist/blacklist for this feature.

I have just tested blender and it still renders on only a single CCX
on mesa from git master. Also, there is a bug report that suggests
this regressed performance in at least one game [1].

If you think enabling it by default is the way to go, we should also
implement a blacklist so that it can be turned off in such cases.

Gustaw Smolarczyk

[1] https://bugs.freedesktop.org/show_bug.cgi?id=108330

More information about the mesa-dev mailing list