Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

On Sat, Oct 21, 2006 at 02:47:56AM +1000, Nick Piggin wrote:

So maybe the COW D$ aliasing patch-series is just the right thing to do.
Not worry about D$ at _all_ when doing the actual fork, and only worry
about it on an actual COW event. Hmm?

Well if we have the calls in there, we should at least make them work
right for the architectures there now. At the moment the flush_cache_mm
before the copy_page_range wouldn't seem to do anything if you can still
have threads dirty the cache again through existing TLB entries.

If you're talking about getting 2.6.19 out of the door without risking
too much wreckage, I'm all for it.

I don't think that flushing on COW is exactly right though, because dirty
data can remain invisible if you're only doing reads (no write, no flush).
And if that cache gets written back at some point, you're going to see
supposedly RO data change underneath you. I think?

You will not be able to avoid aliases at COW breaking time by any kind of
cache flush. In a VIPT cache the userspace page is living at it's
userspace address but the current implemention of copy_user_page will
try to copy it at it's kernel space address and those two may not live
at the same cache index.

So, when breaking a COW mapping you have two options:

1) copying involves touch a userspace mapped page at it's kernel address.
This may result in an alias so apropriate cache flushing will be
needed. On a MIPS system this flush itself is like 1,000 cycles but
could easily several times as much. Add the cost of bringing all the
data that was blown away from the cache back later on.
2) try to be smart and avoid the creation of aliases by creating proper
temporary aliases. Creating and tearing down a TLB mapping is dirt
cheap.

The current strategy is #1 which happens to work for MIPS because there
is at most an alias between clean lines which is harmless on MIPS but will
blow up on PA8800 - without overkill flushing.

It is possible to implement the common sequence of fork + exec such that
the child never ever breaks a COW page, not even a stack page. So why
should a PIPT or VIPT cache be flushed in such a case? We can do better
than that.

Ralf
-
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/

Relevant Pages

  • Re: [PATCH 1/3] Fix COW D-cache aliasing on fork
    ... doing the cache flush at COW time is "kind of equivalent" to just doing it after the TLB flush. ...
    (Linux-Kernel)
  • Re: [PATCH 1/3] Fix COW D-cache aliasing on fork
    ... looking at do_wp_pageI'm now quite concerned about ARM and COW. ... cache as it stands. ... the cache between the userspace mapping and the kernel space mapping before ...
    (Linux-Kernel)
  • Re: [RFC PATCH] ARM: Assume new page cache pages have dirty D-cache
    ... which we've been careful to deal with the cache issues already (eg, ... I think all the copypage functions need to set PG_dcache_clean on the ... Do we do anything other than COW and zero page? ...
    (Linux-Kernel)
  • Re: /var got really big
    ... Others have suggested you clean the apt cache. ... apt-cacher cache rather than have to download the same packages as your ... LVM makes shrinking or expanding filesystems much easier. ... still have plenty of free space on /var so you don't have to worry for ...
    (Ubuntu)
  • Re: Obvious one-liner - Use 3DNOW on MK8
    ... > only a few cache lines are touched in a copied page. ... entire L1 at each fork(). ... 128k copying, 5x5000 loops: ...
    (Linux-Kernel)