Messages in this thread | | | Date | Tue, 15 Nov 2005 10:46:05 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/5] Swap Migration V5: LRU operations |
| |
Christoph Lameter <clameter@engr.sgi.com> wrote: > > On Tue, 15 Nov 2005, Andrew Morton wrote: > > > But lru_add_drain_per_cpu() will be called from interrupt context: the IPI > > handler. > > Ahh.. thought you meant the lru_add_drain run on the local processor. > > > I'm asking whether it is safe for the IPI handler to reenable interupts on > > all architectures. It might be so, but I don't recall ever having seen it > > discussed, nor have I seen code which does it. > > smp_call_function is also used by the slab allocator to drain the > pages. All the spinlocks in there and those of the page allocator (called > for freeing pages) use spin_lock_irqsave. Why is this not used for > lru_add_drain() and friends?
It's a microoptimisation - lru_add_drain() is always called with local irqs enabled, so no need for irqsave.
I don't think spin_lock_irqsave() is notably more expensive than spin_lock_irq() - the cost is in the irq disabling and in the atomic operation.
> Maybe we need to start a new thread so that others see it?
Spose so. If we cannot convince ourselves that local_irq_enable() in an ipi handler is safe, we need to convert any called functions to use irqsave. - 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/
| |