On Fri, 20 Oct 2006, Ralf Baechle wrote:
>
> As a minimal solution your patch would work for MIPS but performance would be
> suboptimal.
Not so.
> With my D-cache alias series applied the flush_cache_mm() in dup_mmap()
> becomes entirely redundant.
No it does not, as pointed out by Nick.
If there are dirty lines in the virtual cache, they _must_ be flushd long
before the COW happens. Because if they are not, they don't show up in the
child of the fork (which only sees it's _own_ virtual cache). See?
> When I delete the call (not part of my patchset) it means 12% faster
> fork. But I'm not proposing this for 2.6.19.
I just suspect it means a _buggy_ fork.
It so happens (I think), that fork is big enough that it probably flushes
the L1 cache _anyway_.
Does MIPS have some kind of "flush_cache_mm()" that could only flush
user-level caches? Maybe the overhead is from flushing all dirty
cachelines, regardless of whether they are kernel or not (and dirty kernel
cachelines are going to be the most common by far in that path).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
