On Sat, Apr 18, 2015 at 03:31:13PM +0200, Martin Sperl wrote: > > On 18.04.2015, at 14:27, Mark Brown <broonie@xxxxxxxxxx> wrote: > > That's probably fine, though the 40ms is a bit on the long side. The > > 30s timeout could use pulling in too, that's going to fail very badly if > > anything does go wronng. > Anything below 2 jiffies will give enough false positives during a kernel > recompile - the original code has had 2 jiffies as the effective minimum, > because the calculated delivery-time of max 30us is still orders of magnitudes > smaller than a single jiffy, but a reschedule can happen, which would be the > main reason why we have had triggered timeouts before. Sure, but with the fallback to a much longer sleeping delay that'd be covered transparently anyway - it doesn't matter if we don't always manage to busy wait under load, what's more important is that we don't fail the operation as a whole. Actually if it's just scheduling that's a concern then one final check after the time expires should do the trick shouldn't it? > SO IMO anything shorter than 2-3 jifies would need to use a new framework to > get access to high-resolution timers - and I do not know how to do that. hrtimer_ is the high resolution timer stuff, though I don't think it's really what you're looking for, it's more about async callbacks IIRC.
Attachment:
signature.asc
Description: Digital signature
