Messages in this thread | | | Date | Mon, 2 Jul 2001 20:23:58 +0900 (JST) | From | NIIBE Yutaka <> | Subject | Cache issues |
| |
NIIBE Yutaka wrote: > I don't see any reason why we need to flush the cache here. > > --- v2.4.6-pre5/mm/memory.c Mon Jun 25 18:48:10 2001 > +++ kernel/mm/memory.c Tue Jun 26 14:48:15 2001 > @@ -1109,8 +1109,6 @@ static int do_swap_page(struct mm_struct > return -1; > } > wait_on_page(page); > - flush_page_to_ram(page); > - flush_icache_page(vma, page); > } > > /*
I've looked thorough all flush_page_to_ram and flush_icache_page calls. If the architecture support follows the rule of Documentation/cachetlb.txt, I think that all the occurrences of flush_page_to_ram and flush_icache_page are (almost) bogus now.
We have two issues yet:
(1) include/linux/highmem.h:memclear_highpage_flush We need to call flush_dcache_page here to remove flush_page_to_ram
(2) kernel/ptrace.c We need to call flush_dcache_page here too. Special care would be needed here. I think that we cannot defer the flushing here. There's the case where page->mapping == &swapper_space, thus mapping->i_mmap == NULL && mapping->i_mmap_shared == NULL.
Besides, flush_cache_page in mm/memory.c:{break_cow,do_wp_page} are redundant for SH-4. SH-4's cache is direct mapped, virtually indexed phisically tagged, so we don't need to flush anything. -- - 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/
| |