On Wed, Apr 15, 2015 at 09:33:48PM +0200, Martin Sperl wrote: > > On 15.04.2015, at 20:58, Mark Brown <[email protected]> wrote:
> > Running without a timeout doesn't feel safe - the standard thing here is > > to busy wait for a short period then fall back to something that sleeps > > if that times out. > That is what is implemented now, but unfortunately the issue is that the > implementation as of now is depending on jiffies, which I found out to be > in the order of 10ms and on top requires a timer interrupt which would > interrupt polling in the first place. But it is still sensitive enough > to trigger on some rescheduling of the polling thread. Then that's not what is implemented... I'd expect something like a busy wait loop done by something like dead reckoning the number of iterations followed by msleep() if we go beyond the busy loop period. > One possibility could be increasing the timeout to something longer like > one second or a fraction of one second. > Something along those lines: > - unsigned long timeout = jiffies + > - max(4 * xfer_time_us * HZ / 1000000, 2uL); > + /* one second timeout - this should also allow for graceful > + * timeouts even when experiencing rescheduling of the thread > + */ > + unsigned long timeout = jiffies + HZ; > Would this be sufficient and acceptable? No, we need to not busy wait for that long. > The patch removing the timeout worked for about 1.47B SPI messages > using the polling code-path now without issues. Sure, if everythinng is working fine then there's never any need to time out - the question is what happens when things go wrong. A hard lockup probably isn't the answer people were looking for there.
signature.asc
Description: Digital signature
