Messages in this thread | | | Date | Thu, 8 Apr 2004 21:02:35 +0200 | From | Andrea Arcangeli <> | Subject | Re: [parisc-linux] rmap: parisc __flush_dcache_page |
| |
On Thu, Apr 08, 2004 at 01:49:55PM -0500, James Bottomley wrote: > Yes, I'll go for that. The write need only be done on vma insert, which > should be very fast. So do we agree this is a generic solution, or were > you still thinking of trying to abstract it per-arch?
I'm unsure, the semaphore simplifies a lot the need_resched() in the vmtruncate/zap_pte path, plus it avoids to waste time in the other cpus while vmtruncate it working on it (potentially for more than a timeslice).
btw, I already considered making the semaphore a rw semaphore (note not a rwspinlock) to boost scalability of the paging too, but OTOH the paging has a so small critical section under the lock (objrmap) that I wasn't sure if it would payoff, the biggest cost will still be the bouncing of the cacheline, so I desisted from the idea of making it a rwsem and I thought the semaphore was ideal as Andrew told me a few days before I had the rwsem idea. Plus concurrent truncate aren't worth optimizing since they're serialized from the i_sem in the first place.
Ideally it should be a semaphore for all archs but the ones who needs to walk it from irqs that wants a rw_spinlock. - 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/
| |