On Tuesday 13 November 2007, Andrew Morton wrote: > > > > Why do you want to use raw_spinlock_t? > > > > Already answered elsewhere in this thread ... > > Can't say I really understood the answer. I don't think we > actually know where all of this extra time is being spent?
Reading that, one could think performance was the only factor. But it isn't, and wasn't the one which really persuaded me. And yes we do where that time went. Although it seems that repeating that info once again won't help... > > I'll highlight the > > point that such bitops shouldn't be preemption points. > > Disagree. *everything* should be a preemption point. So it's wrong that <asm-generic/bitops/atomic.h> uses the same calls to prevent *those* bitops from being prempted? Thus, that code should switch over to normal spinlocks... I believe that if I submitted patches to do that, there'd be a not-so-small riot. And the arguments would all boil down to much the same ones applying to *these* bitops... > For internal-implementation > details we do need to disable preemtion sometimes > (to prevent deadlocks and to protect per-cpu resources). You're certainly talking about "internal-implementation details" in this case. It's not like the lock is used outside of those routines. Or as if other implementations would even *need* such a lock. (Just like the IRQ table, if the entries can't be removed and are all set up very early, locking would be pointless.) > But those > preemption-off periods should be minimised. Like the three instructions in the "hot paths" for getting and setting GPIO values, when using raw spinlocks ... check. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/