On Wed, 2015-08-26 at 21:28 -0400, George Spelvin wrote: > > I can include your patch in the series and then use boolean for the new > > checking_timer field. However, it looks like this applies on an old > > kernel. For example, the spin_lock field has already been removed from > > the structure. > > Apologies; that was 4.1.6. A 4.2-rc8 patch is appended (it's a pretty > trivial merge once you look at it).
Frederic suggested that we just use a single "status" variable and access the bits for the running and checking field. I am leaning towards that method, so I might not include the rest of the boolean changes in this patchset. > > The spinlock call has already been removed from a previous patch. The > > issue now is with contention with the sighand lock. > > I'll look some more and try to wrap my head around it. > > >> Or is it basically okay if this is massively racey, since process-wide > >> CPU timers are inherently sloppy. A race will just cause an expiration > >> check to be missed, but it will be retried soon anyway. > > > Yes, the worst case scenario is that we wait until the next thread to > > come along and handle the next expired timer. However, this "delay" > > already occurs now (for example: a timer can expire right after a thread > > exits check_process_timers()). > > Ad is this polled, or is there some non-polled system that will trigger > another call to check_process_timers(). > > E.g. suppose a process fails to notice that it blew past a CPU time > timeout before blocking. Does anything guarantee that it will get > the timeout signal in finite real time? Yep, the check_process_timers will get called again during the next scheduler interrupt (approximately after 1 jiffy) and send the signal if it finds that the timer expired then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
