On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote: > Hi, > > On 1.3.2019 11.12, Michel Dänzer wrote: > > On 2019-02-28 8:41 p.m., Marek Olšák wrote: > >>> On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen <eero.t.tammi...@intel.com> > >>>> 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. > > > > The last part sounds like Mesa clearly overstepping its authority. > > > > > >> 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. > > > > The fundamental issue here is that Mesa is using the thread affinity API > > for something else than it's intended for. If there was an API for what > > Mesa wants (encouraging certain sets of threads to run on topologically > > close cores), there should be no need to block that. > > Why such process needs to be killed instead the request being masked > suitably, is there some program that breaks subtly if affinity request > is masked (and that being worse than the program being killed)?
But that is still a situation that could be nicely handled with a EPERM error return. Way better than just kill a process. That 'badly affected' program still can call abort then. But nicely working programs don't get just killed then!! best Mathias > > > - eero > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
