lkml.org 
[lkml]   [2001]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectCache 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/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.089 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site