On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-09-07 9:01 p.m., Marek Olšák wrote: >> 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. > > Why not use an RNG API for getting a random number?
It depends on apps calling srand. > > >>> 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. > > Sounds like "640K of memory ought to be enough for anybody"... > > > Anyway, per reports on IRC, the core pinning can hurt even individual > applications, e.g. blender. I like your idea of a driconf option, but it > should be disabled by default, and only enabled for apps where it's > known safe and beneficial in practice. Before we do anything, we can be discuss it with Blender developers or we can add drirc entry for Blender. I don't think we have any other option. Disabling the optimization would make Mesa multithreading slower than singlethreading. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
