On Wed, Jan 03, 2007 at 09:00:58AM -0600, James Bottomley wrote: > However, I was wondering if there might be a different way around this. > We can't really walk all the user mappings because of the locks, but > could we store the user flush hints in the page (or a related > structure)? On parisc we don't care about the process id (called space > in our architecture) because we've turned off the pieces of the cache > that match on space id. Thus, all we care about is flushing with the > physical address and virtual address (and only about 10 bits of this are > significant for matching). We go to great lengths to ensure that every > mapping in user space all has the same 10 bits of virtual address, so if > we just new what they were we could flush the whole of the user spaces > for the page without having to walk any VMA lists. Could arm do this as > well?
I don't think so. The organisation of the VIVT caches in terms of how the set index and tag correspond with virtual addresses are hardly ever documented. When they are, they don't appear to lend themselves to such an approach. For example, Xscale has: tag: virtual address b31-10 set index: b9-5 and there's 32 ways per set. So there's nothing to be gained from controlling the virtual address which individual mappings end up at in this case. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
