Re: question on irqs and memory ordering
Oliver Neukum <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
Am Mittwoch, 14. März 2007 23:44 schrieb David Howells: > 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: OK, thanks. I am relieved. Should I add a section concerning this to Documentation? Regards Oliver ------------------------------------------------------------------------- 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