[PATCH RESEND v8] iopoll: Introduce memory-mapped IO polling macros
Elliott, Robert (Server Storage)
Elliott at hp.com
Mon Nov 24 19:02:30 PST 2014
> -----Original Message-----
> From: Mitchel Humpherys [mailto:mitchelh at codeaurora.org]
> Sent: Monday, November 24, 2014 7:21 PM
> To: Elliott, Robert (Server Storage)
> > The hpsa SCSI driver used to use usleep_range in a loop like
> > that, but we found that it caused scheduler problems during
> > boots because it uses TASK_UNINTERRUPTIBLE:
> > [ 9.260668] [sched_delayed] sched: RT throttling activated
> > msleep() worked much better.
Sorry, that might have been msleep_interruptible() - the fixes
are still not upstream, so I'll have to doublecheck tomorrow.
> Hmm, maybe you were just sleeping for too long? According to
> Documentation/timers/timers-howto.txt, usleep_range is what should be
> used for non-atomic sleeps in the range [10us, 20ms]. Plus we need
> microsecond granularity anyways, so msleep wouldn't cut it.
The intervals and the overall number of loops were indeed long. I
think the corrected code waits a total of 1 second; before the fix,
> If there are any potential users of these macros that would want to
> sleep for more than 20ms I guess we could add a special case here to use
> msleep when sleep_us exceeds 20,000 or so.
Maybe just a comment in the documentation for the macro would suffice,
possibly with a separate macro for longer interval sleeps. I don't
want to force an extra msleep() call to be compiled into a bunch
of places where it's not needed.
Rob Elliott HP Server Storage
More information about the linux-arm-kernel