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/
This archive was generated by hypermail 2b29 : Sat Jul 07 2001 - 21:00:10 EST