linux-kernel - Re: When is a wake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1239244727.19075.34.camel@palomino.walls.org>
Date:	Wed, 08 Apr 2009 22:38:46 -0400
From:	Andy Walls <awalls@...ix.net>
To:	Trent Piepho <xyzzy@...akeasy.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-media@...r.kernel.org
Subject: Re: When is a wake_up() not a wake up?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/