Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992720AbWJTWEp (ORCPT ); Fri, 20 Oct 2006 18:04:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S2992886AbWJTWEp (ORCPT ); Fri, 20 Oct 2006 18:04:45 -0400 Received: from smtp.osdl.org ([65.172.181.4]:18059 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S2992880AbWJTWEn (ORCPT ); Fri, 20 Oct 2006 18:04:43 -0400 Date: Fri, 20 Oct 2006 15:02:39 -0700 (PDT) From: Linus Torvalds To: Ralf Baechle cc: David Miller , nickpiggin@yahoo.com.au, Andrew Morton , Linux Kernel Mailing List , anemo@mba.ocn.ne.jp, linux-arch@vger.kernel.org, Martin Schwidefsky , James Bottomley Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork In-Reply-To: <20061020214916.GA27810@linux-mips.org> Message-ID: References: <20061020.123635.95058911.davem@davemloft.net> <20061020.125851.115909797.davem@davemloft.net> <20061020214916.GA27810@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1308 Lines: 37 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/