2001-07-02 11:24:28

by NIIBE Yutaka

[permalink] [raw]
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.
--


2001-07-02 22:48:34

by David Miller

[permalink] [raw]
Subject: Re: Cache issues


NIIBE Yutaka writes:
> 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.

Unfortunately several ports still use the old calls and do not make
use of flush_dcache_page etc.

So these older intefaces may not be arbitrarily removed in 2.4.x

The goal is to eventually remove them, this is true. But it must
be done in 2.5.x at the earliest.

Later,
David S. Miller
[email protected]

2001-07-03 00:05:09

by NIIBE Yutaka

[permalink] [raw]
Subject: Re: Cache issues

David S. Miller wrote:
> So these older intefaces may not be arbitrarily removed in 2.4.x
>
> The goal is to eventually remove them, this is true. But it must
> be done in 2.5.x at the earliest.

Yes, agreed.

I mean, it's almost ready for port maintainers to migrate new
interface (only two issues remain:
include/linux/highmem.h:memclear_highpage_flush and ptrace), as soon
as 2.5.x starts.

For the time being, I let SH-4 port have null definitions of
flush_page_to_ram and flush_icache_page, and see how things are going.
--