Messages in this thread | | | Subject | Re: [parisc-linux] rmap: parisc __flush_dcache_page | From | James Bottomley <> | Date | 08 Apr 2004 13:28:17 -0500 |
| |
On Thu, 2004-04-08 at 13:18, Andrea Arcangeli wrote: > it enterely depends on the workload. On a desktop machine there may be > only some hundred entries in those lists at maximum with glibc being the > biggest offender: > > cat /proc/*/maps | grep libc.so.6 | wc -l > > with shared memory on some server there can be easily several thousand > entries for some inode even on 64bit, but a timeslice was probably > exaggerated (the timeslice was for the walking of the ptes in each > mapping too, I don't think you need to look at every pte).
So you're worried about our code? OK, if you look, you'll see we only have to flush one address in the mmap_shared list, (which is usually the long list).
I'd constructed it on the predicate that flushing a non-current space is more expensive than finding a current one, but I can alter it to flush the first vma it comes to with a present translation.
The mmap list is usually empty. We only excite that case for multiple private mappings of a file which for some reason gets updated.
I'd be very surprised if flush_dcache_page executes more than a few hundred instructions all told...that's certainly nowhere close to a timeslice.
James
- 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/
| |