Re: When is a wake_up() not a wake up?

[Andy Walls <awalls@radix.net>]

On Sat, 2009-04-04 at 04:07 -0700, Trent Piepho wrote:
> On Fri, 3 Apr 2009, Andy Walls wrote:
> > 1. A work queue thread or read() call needs to send a command to the
> > CX23418 using the cx18_api_call() function
> > 2. It fills out a mailbox with a command for the CX23418
> > 3. It prepares to wait, just in case a wait is needed
> > 4. A SW1 interrupt is sent to the CX23418 telling it a mailbox is ready
> > 5. The ack filed in the mailbox, a PCI MMIO location, is checked to see
> > if the mailbox was ack'ed already
> > 6. If not, schedule_timeout() for up to 10 msecs (a near eternity...)
> > 7. Clean up the wait and move on
> 
> 10ms isn't that long.  With a 100 HZ kernel it's only one jiffie.  The
> shortest time msleep() can sleep on a 100 HZ kernel is 20 ms.
> 
> Is it possible that it's simply taking more than 10 ms for your process to
> get run?

After some testing with fine grained timestamps as you suggested, that
indeed appears to be the case.

For the high volume API command I care about, in 6097 out of 6100
samples, the firmware acknowledgment interrupt comes back in and the
process is awakened back to TASK_RUNNABLE in under 150 us.  0 out of
6100 samples finished the wakeup to TASK_RUNNABLE faster than 55 us.
However, I had 22 samples, where coming back from schedule_timeout()
took 10 msec or greater, despite the wakeup happening in under 150 us.

So the simple answer is to poll the ack field of the mailbox, with some
50 us busy waits perhaps, for this one high volume API command.

Regards,
Andy