> -----Original Message----- > From: Mitchel Humpherys [mailto:mitch...@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, 600 seconds. > 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 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
