Hi Michael, On 05/11/18 16:31, Michael Kerrisk (man-pages) wrote: > Hello Claudio, > > Sorry -- I ran out of time in the last months. Now I return to tthis. > > On Tue, 12 Jun 2018 at 20:09, Claudio Scordino <claudio@xxxxxxxxxxxxxxx> wrote: > > > > Hi Michael, > > > > how do we move forward from this situation ? > > > > The kernel source [1] and the related documentation [2] have been > > already updated to include both the SCHED_FLAG_RECLAIM and > > SCHED_FLAG_DL_OVERRUN flags. > > > > Now, it's time to update the sched_setattr() manpage as well (even if > > the SIGXCPU signal is per-process and not per-thread). > > > > Many thanks and best regards, > > So, I have captured pretty much everything of our discussion (starting > from your initial patch) in manual page updates in the > sched_setattr(2) page. The text currently since in a private branch in > my local Git. The text also tries to capture what I beleive is the bug > with SIGXCPU being process directed instead of thread-directed: > > SCHED_FLAG_DL_OVERRUN (since Linux 4.16) > This flag allows an application to get informed > about run-time overruns in SCHED_DEADLINE threads. > Such overruns may be caused by (for example) coarse > execution time accounting or incorrect parameter > assignment. Notification takes the form of a SIGX‐ > CPU signal which is generated on each overrun. > > This SIGXCPU signal is process-directed (see sig‐ > nal(7)) rather than thread-directed. This is proba‐ > bly a bug. On the one hand, sched_setattr() is > being used to set a per-thread attribute. On the > other hand, if the process-directed signal is deliv‐ > ered to a thread inside the process other than the > one that had a run-time overrun, the application has > no way of knowing which thread overran. > > The question is: is there any plan to change this behavior, probably > in the direction of Luca's idea to have a per-process signal > that passes some info about which thread overran? Even though what Luca proposed might be helpful, it seems that we currently direct the signal to the right thread? Your question made me check again and you are right in saying that we are calling check_dl_overrun in check_process_timers, but this is wrong, even though harmless, since we are already calling the same from check_ thread_timers. Anyway, I believe this latter call does the right thing, directing the signal to the overrunning thread. Do you agree? Just sent a patch upstream to remove the call from check_process_ overrun. Best, - Juri
