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? >> 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
