Messages in this thread | | | Subject | Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread. | From | Arjan van de Ven <> | Date | Fri, 5 Feb 2016 18:54:33 -0800 |
| |
>> 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.
| |