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

Haehnle, Nicolai Nicolai.Haehnle at amd.com
Mon Nov 5 10:09:08 UTC 2018


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.

Cheers,
Nicolai


> 
> Marek
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


More information about the mesa-dev mailing list