Messages in this thread | | | Date | Mon, 28 Oct 2002 16:36:49 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH] shmem missing cache flush |
| |
On Mon, Oct 28, 2002 at 06:26:08AM -0800, David S. Miller wrote: > If you can't get purely arch/* include/asm-* patches to him, > that isn't my problem. > > Yes, you might have to retransmit that patch 20/30 times over the > course of a few days depending upon how busy Linus is, just get over > it. :-)
I've been more concerned with getting core changes we need to him than updating arch/parisc and include/asm-parisc. Maybe I should have been more pushy.
> What do you want to do about flush_icache_page? You want to change it > to flush_dcache_page at eviction time, and then we can purge that page > from our icache in update_mmu_cache? > > That's the idea. The other idea is "well these particular call spots > really are special, so let's document flush_icache_page properly".
What data do you need to make that decision? AFAICT (I'm not really a PA CPU guru..) it's exactly the same amount of code, no matter which way we do it.
While we're on the subject of cache flushing... these make no sense:
fs/binfmt_aout.c:357: flush_icache_range(text_addr, text_addr+ex.a_text+ex.a_data); fs/binfmt_aout.c:381: flush_icache_range((unsigned long) N_TXTADDR(ex), fs/binfmt_aout.c:479: flush_icache_range((unsigned long) start_addr, fs/binfmt_elf.c:422: flush_icache_range((unsigned long)addr,
the kernel doesn't execute the code ranges here, userspace does. Which means that the only place in the entire kernel which does need to call flush_icache_range() is kernel/module.c, and that could all be done in module_arch_init(). So I think we don't need flush_icache_range() at all.
-- Revolutions do not require corporate support. - 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/
| |