Re: [RFC PATCH] Update the cachetlb.txt file WRT flush_dcache_pageand update_mmu_cache

[FUJITA Tomonori]

On Fri, 07 May 2010 14:24:18 +0100
Catalin Marinas <catalin.marinas@xxxxxxx> wrote:

>    void flush_dcache_page(struct page *page)
>  
> -	Any time the kernel writes to a page cache page, _OR_
> +	Any time the kernel modifies an existing page cache page, _OR_
>  	the kernel is about to read from a page cache page and
>  	user space shared/writable mappings of this page potentially
>  	exist, this routine is called.
> @@ -289,20 +295,26 @@ maps this page at its virtual address.
>  	      handling vfs symlinks in the page cache need not call
>  	      this interface at all.
>  
> +	      The kernel may not call this function on a newly allocated
> +	      page cache page even though it stored data into the page.
> +
>  	The phrase "kernel writes to a page cache page" means,
>  	specifically, that the kernel executes store instructions
>  	that dirty data in that page at the page->virtual mapping
>  	of that page.  It is important to flush here to handle
>  	D-cache aliasing, to make sure these kernel stores are
> -	visible to user space mappings of that page.
> +	visible to user space mappings of that page. It is also
> +	important to flush the cache on Harvard architectures where the
> +	I and D caches are not coherent.
>  
>  	The corollary case is just as important, if there are users
>  	which have shared+writable mappings of this file, we must make
>  	sure that kernel reads of these pages will see the most recent
>  	stores done by the user.
>  
> -	If D-cache aliasing is not an issue, this routine may
> -	simply be defined as a nop on that architecture.
> +	If D-cache aliasing is not an issue and the I and D caches are
> +	unified, this routine may simply be defined as a nop on that
> +	architecture.
>  
>          There is a bit set aside in page->flags (PG_arch_1) as
>  	"architecture private".  The kernel guarantees that,
> @@ -312,15 +324,15 @@ maps this page at its virtual address.
>  	This allows these interfaces to be implemented much more
>  	efficiently.  It allows one to "defer" (perhaps indefinitely)
>  	the actual flush if there are currently no user processes
> -	mapping this page.  See sparc64's flush_dcache_page and
> -	update_mmu_cache implementations for an example of how to go
> +	mapping this page.  See IA-64's flush_dcache_page and
> +	set_pte_at implementations for an example of how to go
>  	about doing this.

cachetlb.txt says that flush_dcache_page() is the API to solve the
D-cache aliasing issue. Using IA64 as an example for the API here
looks strange since IA64 (PIPT) doesn't have D-cache aliasing
issue.

I don't think that just replacing sparc64 with IA64 helps much here
since we still have the problem that the whole cache handling
(architectures, subsystems, file systems) is inconsistent. I think
that we need to agree on it first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/