> So then a >100us delay is ok ?
>
> I have a dumb RT perspective: either you have to make the deadline or you don't.
> If you have to make the deadline, then why are you checking need_resched?
In the case I'm describing, it _works_ if you have a >100us delay. We ask
the chip to do something, and we expect it to take about 100us, so we come
back and start polling for completion after that time. Actually, we tune
our estimate of how long to back off, depending on how long we've actually
spent polling for completion on previous attempts. But if you _always_
have a 10ms delay, each time you only really needed to wait 100us, then
the performance is appalling.
I'd like to be nice, but I don't want to drop my performance by 100x
without good reason. Hence the check for need_resched.
Don't confuse this with the code which was mentioned before, which needs
to send many different words to the chip consecutively. That is done while
holding a spin_lock. We don't drop the lock and wait between commands in
that situation.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/