FYI, starting with AMD Ryzen, multithreaded apps and libs pretty much have to change thread affinity to get good performance out of multithreading.
Marek On Thu, Feb 28, 2019, 11:41 AM Marek Olšák <mar...@gmail.com> wrote: > On Thu, Feb 28, 2019 at 11:13 AM Marc-André Lureau < > marcandre.lur...@gmail.com> wrote: > >> Hi Eero! >> >> (ex-colleagues, long time ago!) >> >> On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen <eero.t.tammi...@intel.com> >> wrote: >> > >> > Hi, >> > >> > On 28.2.2019 11.57, Marc-André Lureau wrote: >> > > On Thu, Feb 28, 2019 at 1:17 AM Marek Olšák <mar...@gmail.com> wrote: >> > >> I'd rather have something more robust than an env var, like catching >> SIGSYS. >> > >> > SIGSYS is info for the invoking parent, not the (Mesa) process doing the >> > syscall. >> > >> > From "man 2 seccomp": >> > >> > The process terminates as though killed by a SIGSYS signal. Even if a >> > signal handler has been registered for SIGSYS, the handler will be >> > ignored in this case and the process always terminates. To a parent >> > process that is waiting on this process (using waitpid(2) or similar), >> > the returned wstatus will indicate that its child was terminated as >> > though by a SIGSYS signal. >> > >> > >> > > With current qemu in most distros, it defaults to SIGSYS (we switched >> > > away from SCMP_ACT_KILL, which had other problems). With more recent >> > > qemu/libseccomp, it will default to SCMP_ACT_KILL_PROCESS. In those >> > > KILL action cases, mesa will not be able to catch the failing >> > > syscalls. >> > >> > Qemu / libvirt isn't the only thing using seccomp. >> > >> > For example Docker enables seccomp filters (along with capability >> > restrictions) for the invoked containers unless that is explicitly >> > disabled: >> > https://docs.docker.com/engine/security/seccomp/ >> > >> > What actually gets filtered, is trivially changeable on Docker command >> > line by giving a JSON file specifying the syscall filtering. >> > >> > Default policy seems to be white-listing affinity syscall: >> > >> https://github.com/moby/moby/blob/master/profiles/seccomp/default.json >> > >> > >> > Why distro versions of Qemu filter sched_setaffinity() syscall? >> > >> > >> >> (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815889) >> >> Daniel Berrange (berrange) wrote on 2019-02-27: #19 >> >> "IMHO that mesa change is not valid. It is settings its affinity to >> run on all threads which is definitely *NOT* something we want to be >> allowed. Management applications want to control which CPUs QEMU runs >> on, and as such Mesa should honour the CPU placement that the QEMU >> process has. >> >> This is a great example of why QEMU wants to use seccomp to block >> affinity changes to prevent something silently trying to use more CPUs >> than are assigned to this QEMU." >> > > Mesa uses thread affinity to optimize memory access performance on some > CPUs (see util_pin_thread_to_L3). Other places in Mesa need to restore the > original thread affinity for some child threads. Additionally, if games > limit the thread affinity, Mesa needs to restore the full thread affinity > for some of its child threads. > > In essence, the thread affinity should only be considered a hint for the > kernel for optimal performance. There is no reason to kill the process if > it's disallowed. Just ignore the call or modify the thread mask to make it > legal. > > Marek >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
