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

[Eric Anholt]

"Haehnle, Nicolai" <Nicolai.Haehnle at amd.com> writes:

> 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.

I completely agree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181105/07165715/attachment.sig>