kgdb: Use atomic operators which use barriers
in [Kernel]
|
Prev: [tip:sched/core] sched: move_task_off_dead_cpu(): Take rq->lock around select_fallback_rq()
Next: [tip:perf/core] perf, x86: Add Nehalem programming quirk to Westmere
From: Russell King - ARM Linux on 2 Apr 2010 18:30 On Fri, Apr 02, 2010 at 12:43:00PM -0700, Linus Torvalds wrote: > Russell is wrong. Actually, in future threads you end up agreeing with my position... > The fact that maybe some ARM6 cache coherency implementation is pure and > utter sh*t and never sees the changes without the same instruction that > happens to be a memory barrier on that architecture does not make that > cpu_relax() any more about memory barriers. I'm not going to discuss it now; I'm on holiday. Wait until mid-next week on this and I'll respond with a fuller reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 2 Apr 2010 19:30 On Fri, 2 Apr 2010, Russell King - ARM Linux wrote: > > Actually, in future threads you end up agreeing with my position... I always agreed that it was not a memory barrier. In fact, the commit that extended on the "volatile-considered-harmful" patch from you has this quote from me in the commit logs: Linus sayeth: : I don't think it was ever the intention that it would be seen as anything : but a compiler barrier, although it is obviously implied that it might : well perform some per-architecture actions that have "memory barrier-like" : semantics. : : After all, the whole and only point of the "cpu_relax()" thing is to tell : the CPU that we're busy-looping on some event. : : And that "event" might be (and often is) about reading the same memory : location over and over until it changes to what we want it to be. So it's : quite possible that on various architectures the "cpu_relax()" could be : about making sure that such a tight loop on loads doesn't starve cache : transactions, for example - and as such look a bit like a memory barrier : from a CPU standpoint. : : But it's not meant to have any kind of architectural memory ordering : semantics as far as the kernel is concerned - those must come from other : sources. which I think is pretty clear. But that quote seems to be the one where you then think I "agree" with you. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 3 Apr 2010 12:10 On Fri, Apr 02, 2010 at 04:24:57PM -0700, Linus Torvalds wrote: > > > On Fri, 2 Apr 2010, Russell King - ARM Linux wrote: > > > > Actually, in future threads you end up agreeing with my position... > > I always agreed that it was not a memory barrier. > > In fact, the commit that extended on the "volatile-considered-harmful" > patch from you has this quote from me in the commit logs: > > Linus sayeth: > > : I don't think it was ever the intention that it would be seen as anything > : but a compiler barrier, although it is obviously implied that it might > : well perform some per-architecture actions that have "memory barrier-like" > : semantics. > : > : After all, the whole and only point of the "cpu_relax()" thing is to tell > : the CPU that we're busy-looping on some event. > : > : And that "event" might be (and often is) about reading the same memory > : location over and over until it changes to what we want it to be. So it's > : quite possible that on various architectures the "cpu_relax()" could be > : about making sure that such a tight loop on loads doesn't starve cache > : transactions, for example - and as such look a bit like a memory barrier > : from a CPU standpoint. > : > : But it's not meant to have any kind of architectural memory ordering > : semantics as far as the kernel is concerned - those must come from other > : sources. > > which I think is pretty clear. > > But that quote seems to be the one where you then think I "agree" with > you. Yet again you read something into what I say that wasn't there. Wait for me to return from holiday, as I said, and I'll respond further. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 5 Apr 2010 05:30 Hi! > > Russell had this thread: > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/75717 > > Russell is wrong. > > Yes, originally it was about P4's overheating. But let me repeat: the fact > is, this _is_ valid kernel code: > > kernel/sched.c- while (task_is_waking(p)) > kernel/sched.c: cpu_relax(); And this is valid (but ugly and not optimal) kernel code: kernel/sched.c- while (task_is_waking(p)) kernel/sched.c: asm volatile("" :: "memory"); > (where that "task_is_waking()" is simply doing two regular reads, and > expects another CPU to be changing them). > > This has _nothing_ to do with memory barriers, or with overheating. .... > All that matters is that the above kind of while loop must work. The > architecture needs to do whatever it needs to do to make it work. End of > discussion. If on ARM6 that means "smp_mb()", then that's an ARM6 > implementation issue. ....so I don't think inserting smp_mb() into cpu_relax() and udelay() and similar can ever fix the problem fully. Run smp_mb() from periodic interrupt? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 5 Apr 2010 11:10
On Mon, 5 Apr 2010, Pavel Machek wrote: > > And this is valid (but ugly and not optimal) kernel code: > > kernel/sched.c- while (task_is_waking(p)) > kernel/sched.c: asm volatile("" :: "memory"); No. We would consider such code buggy. That said, you're right that such code would exist. But if it were to exist and cause lock-ups, at least I would consider it a simple and outright bug, and that the proper fix would be to just replace the asm with cpu_relax(). > ...so I don't think inserting smp_mb() into cpu_relax() and udelay() > and similar can ever fix the problem fully. See above. > Run smp_mb() from periodic interrupt? Doesn't help - it's quite valid to do things like this in irq-disabled code, although it is hopefully very very rare. In particular, I suspect the kgdb use _is_ interrupts disabled, and is why the ARM people even noticed (the normal cases would break out of the loop exactly because an interrupt occurred, and an interrupt is probably already enough to make the issue go away). And please do not confuse this with smp_mb() - this is not about the Linux notion of a memory barrier, this is about whatever per-arch oddity that makes changes not be noticed (ie caches may be _coherent_, but they are not "timely"). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |