Question about cache flushing and fork

Question about cache flushing and fork

[Randolph Chung]

Hi,

Can someone please explain why it is necessary to flush the cache 
during fork()? (i.e. call to flush_cache_mm() in dup_mmap)

It seems that after fork, the parent and child have access to the same
vm, so it should be sufficient to flush the tlb, and create two pte's
for the processes. I can see that during COW processing there can be
kernel/user cache aliasing issues on virtually indexed caches, but
that seems to be taken care of by copy_cow_page(). 

I've read through cachetlb.txt, but it just says:

        This interface is used to handle whole address space
        page table operations such as what happens during
        fork, exit, and exec.

I can see why this is needed for exit(), but why fork()? and i don't see
this used for exec() ?

Also is there an updated version of the "Linux Cache Flush Architecture"
document? (http://en.tldp.org/LDP/khg/HyperNews/get/memory/flush.html)
This is a very nicely written doc, but it seems a bit out of date for
2.6 (e.g. flush_page_to_ram is gone)

thanks
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: Question about cache flushing and fork

[David S. Miller]

On Mon, 15 Dec 2003 20:40:33 -0800
Randolph Chung <randolph@tausq.org> wrote:

> Can someone please explain why it is necessary to flush the cache 
> during fork()? (i.e. call to flush_cache_mm() in dup_mmap)

Writable pages that will be shared between the child and
parent are marked read-only and COW, some cpu caches store
protection information in the cache lines in order to avoid
TLB lookups etc. so the caches must be flushed since the
page protection information is changing.

Re: Question about cache flushing and fork

[Linus Torvalds]

On Mon, 15 Dec 2003, Randolph Chung wrote:
>
> Can someone please explain why it is necessary to flush the cache
> during fork()? (i.e. call to flush_cache_mm() in dup_mmap)

I don't know if it is strictly necessary - we might well be able to just
do the right thing in the page fault COW handler. But doing the cache
flush at fork time just means that we should never have a page that is
marked read-only but that may have dirty data in the virtual caches. That
could easily get confusing. In fact, I wouldn't be totally surprised if
some architecture refused to do write-backs through a read-only mapping.

But quite frankly, I suspect that since only a few CPU's have virtually
indexed caches, the cache-flush code hasn't gotten that much testing, and
there may be somewhat of an overkill approach there. As you found out,
it's not _that_ well documented.

		Linus

Re: [parisc-linux] Re: Question about cache flushing and fork

[LaMont Jones]

On Mon, Dec 15, 2003 at 08:48:35PM -0800, David S. Miller wrote:
> On Mon, 15 Dec 2003 20:40:33 -0800
> Randolph Chung <randolph@tausq.org> wrote:
> > Can someone please explain why it is necessary to flush the cache 
> > during fork()? (i.e. call to flush_cache_mm() in dup_mmap)
> Writable pages that will be shared between the child and
> parent are marked read-only and COW, some cpu caches store
> protection information in the cache lines in order to avoid
> TLB lookups etc. so the caches must be flushed since the
> page protection information is changing.

On PARISC, the cache line contains the following elements:
	1) data (obviously)
	2) physical page
	3) dirty/clean/public/private/etc state

A cache access hits or misses depending on whether or not the physical page from
the TLB matches the physical page stored in the cache line.

If flushing is required during fork on PARISC, then there are cache consistency
issues elsewhere, something is horribly broken in the design (and it should be
falling all over anyway).

lamont