On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-09-07 4:31 p.m., Marek Olšák wrote: >> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer <mic...@daenzer.net> wrote: >>> On 2018-09-06 10:56 p.m., Axel Davy wrote: >>> >>>> I fear if we begin to do the work manually, there won't be interest to >>>> do that in the kernel, >>>> and thus all applications will need to include such core pinning code to >>>> have good performance when >>>> multithreaded. >>> >>> I'm also a bit worried that this solution could result in multiple >>> processes contending for the same set of CPU cores, while other cores >>> might be underused, which could result in worse overall system performance. >> >> Any suggestion how to choose the ccx such that processes end up on a >> different one? > > One thing you could do is use a random initial offset. That should at > least avoid e.g. most applications using the same toolkit (which may do > OpenGL calls, even if the application itself doesn't) choosing the same one.
I'll update the helper function to choose the initial CCX with (os_time_get_nano() % num_L3_caches). That should be random. > > >> I don't think the performance can be worse than it is right now. > > In the worst case, all processes using OpenGL (or at least their OpenGL > related threads, but that usually includes the main thread) could end up > restricted to the same 4 cores, leaving up to 28 cores underused. 4C/4T used to be a standard and certainly enough for gaming. 4C/8T used to be luxury before Ryzen, which is now the CCX. We should be fine with 4 cores. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
