![]() | |||||||||||||
Messages in this thread |
* Christoph Hellwig <hch@infradead.org> wrote: > On Tue, Jan 04, 2005 at 10:04:08AM +0100, Ingo Molnar wrote: > > or is it the addition of _smp_processor_id() as a way to signal 'this > > smp_processor_id() call in a preemptible region is fine, trust me'? > > Yes. > > > We > > could do smp_processor_id_preempt() or some other name - any better > > suggestions? > > I'd just kill the debug check and rely on the eye of the review to not > let new users of smp_processor_id slip in. relying on that is quite futile. E.g. in the block IO code it needed 3-4 iterations even after the first instance was found to get all the cases right. There are functions that are always called from under a lock then some unlocked call happens and we've got trouble. Often the bug is some very rare and obscure corruption of a statistics value, nobody really notices that. by today i think we've identified most of the places that can safely do smp_processor_id() in a preemptible section (in x86 and x64) - it's only around 3% of the total smp_processor_id() use. I'd rather allow these exceptions and flag new exceptions as they get added - they are added at least an order of magnitude more rarely than smp_processor_id() gets added. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:09 [from the cache] ©2003-2008 | |||||||||||||