On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: > On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: > ... > > > First of all, if you know that there is already a hardclock/statclock/* > > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > > a new one. > > > > That is true, but my main point was about merging with external events, > > which I can't predict and the only way to merge is increase sleep period, > > hoping for better. > > ok, now i understand why you want to schedule for T_X+D. > > Probably one way to close this discussion would be to provide > a sysctl so the sysadmin can decide which point in the interval > to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ?
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC