Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> I think he is concerned about CPU A executing an interrupt handler, its
> stores getting stuck in its store buffer or its write-back cache, the IRQ
> finished, IRQ get migrated to CPU B, CPU B taking next interrupt and seeing
> old RAM state. I don't see this possible, because we take too many
> spinlocks when IRQ is processed and they definitely drain store buffers and
> caches. Not to mention the IRQ migration from A to B...
I agree. Unless the IRQ is bound to a particular CPU (in which case it can't
exhibit the behaviour in question), it will lock and unlock the IRQ descriptor
spinlock at least once each side of executing a chain of handlers, and whilst
it's executing the handlers, it may not migrate. This means you get, in
effect, a full memory barrier either side of a handler:
CPU 0 CPU 1
=============================== ===============================
-->__do_IRQ()
spin_lock(&desc->lock);
...
spin_unlock(&desc->lock);
handle_IRQ_event();
spin_lock(&desc->lock); -->__do_IRQ()
... spin_lock(&desc->lock);
spin_unlock(&desc->lock); ...
spin_unlock(&desc->lock);
handle_IRQ_event();
spin_lock(&desc->lock);
...
spin_unlock(&desc->lock);
A handler for an IRQ that isn't bound to a CPU has a LOCK-class memory barrier
before it - in which case any memory accesses it performs must happen after
any memory accesses from before the lock - and it has an UNLOCK-class memory
barrier after it - in which case any memory accesses it performs must happen
before any memory accesses that occur after the unlock.
The fact that there is an extra UNLOCK-class memory barrier between the lock
and the handler and an extra LOCK-class memory barrier between the handler and
the unlock is irrelevant. It's like putting in extraneous memory barriers in
your code: they won't make your code malfunction, but they will slow things
down.
In this particular case you can't, however, get rid of them because they have
other necessary side-effects too.
David
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
