Re: question on irqs and memory ordering

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel