and most of the RT guys would only tolerate a little bit of it
is there any real/practial use of going longer than 4 seconds? if there
is then yeah fixing it makes sense.
if it's just theoretical... shrug... 32 bit systems have a bunch of
other limits/differences a well.
So I'd think it would be mostly theoretical, but in my testing on a
VM, setting the timerslack for bash to 10 secs made time sleep 1 take
~10.5 seconds. So its apparently not too hard to coalesce fairly far
out (I need to spend a bit more time to verify that events really
weren't happening during that time and we're not just doing
unnecessary delays with the extra slack).
99% sure you're hitting something else;
we look pretty much only 1 ahead in the queue for timers to run to see if
they can be run, once we hit a timer that's not ready yet we stop.
your 10 second ahead is behind a whole bunch of other not-ready ones
so won't even be looked at until its close
But yea. My main concern is that if we do a consistent 64bit interface
for all arches in the /proc/<pid>/timerslack_ns interface, it will
make PR_GET_TIMERSLACK return incorrect results on 32bit systems when
the slack is >= 2^32.
or we return UINT_MAX for that case. not too hard.
