[parisc-linux] rmap: parisc __flush_dcache_page
Andrea Arcangeli
andrea at suse.de
Thu Apr 8 13:02:35 MDT 2004
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.
More information about the parisc-linux
mailing list