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

[Marek Olšák]

On Mon, Nov 5, 2018 at 5:09 AM Haehnle, Nicolai <Nicolai.Haehnle at amd.com>
wrote:

> On 31.10.18 21:41, Marek Olšák wrote:
> > Instead of saying that, you should say "Mesa should be slower with most
> > apps, so that we don't decrease perf for 2 apps too much", because
> > that's what you are saying. It seems like you have some limited belief
> > that only allows you to see the problem on one side (2 apps
> > significantly slower) and prevents you from seeing the problem on the
> > other side (most apps slower), so for some twisted reason or because you
> > just wanna have the feeling of "being right", you would rather see most
> > apps slower than 2 apps significantly slower. I don't give a damn if I'm
> > right. I could be wrong all day and learn. And you shouldn't give a damn
> > if you are right either, because if you do, it shows a fragile ego. I'm
> > looking for objectively the best solution with the least maintenance.
> > The patch on the mailing list gives me the least maintenance as far as I
> > can tell. If you have another solution that needs just as little
> > maintenance, I'm all ears.
>
> So, on a personal level, I feel like maybe your phrasing was a bit harsh
> and could be toned down.
>
> On the technical level, the problem is that while yes, only a small
> number of apps are negatively affected, the negative effect as reported
> is *absolutely massive*. The positive effect of the affinity hack, on
> the other hand, is obviously decent and very welcome, but unfortunately
> nowhere near as big.
>
> The reality of users is that most of them don't complain when they're
> confronted with sucky software. Or they complain within their circles,
> slowly contributing to a negative reputation of the software in a way
> that doesn't reach us. (That's a general pattern which causes most
> software to suck more than necessary.)
>
> We (and really mostly you of all people) have worked very hard to
> improve our reputation for producing great drivers. We shouldn't
> squander that.
>
> So I think on the technical merits, the others on this thread are right.
> The explicit affinity setting was a good initiative and turned out to be
> very useful, but unfortunately we really need to go with a whitelisting
> approach at this point, while making sure that the whitelist option gets
> good exposure on Phoronix et al.
>
> The real long-term solution would be anyway to figure out why the kernel
> doesn't do a good job of placing the Gallium driver thread on the right
> CCX, and then fixing that. To be honest, I've always thought that
> the explicit affinity approach is more of a hack. And the proper
> long-term approach is quite likely to help improve the performance of
> Ryzen / Threadripper / EPYC in general, not just for Mesa. But my
> educated guess is that that's not something any of us can do in a week
> (though I'd be happy for you to prove me wrong :)), and in any case, it
> takes a long time for kernel improvements like that to filter through to
> end users, so going with a whitelist seems the right thing to do either
> way.
>

So you are saying that there is no solution for Ryzen. The whitelist would
not be maintainable. It would mostly just contain benchmarks run by
Phoronix + a couple of games maybe. I added a lot of the entries for
glthread and I learned how much whitelists suck. Our competition can have
whitelists because they have plenty of people updating them constantly. If
Michel wanted to be the guy to build that whitelist and update it
regularly, I'd be OK with having the whitelist.

I'm actually fine with GTK and Qt apps being stuck on the same CCX, because
the majority of them don't use any heavy multithreading and 4C/8T is enough.

Yes, it sucks.

I'm not gonna do anything about it at this point. I can push the patches
that add the blacklist approach, or you can disable the current code
completely or add the whitelist if that's what you prefer.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181105/19088fc8/attachment.html>