From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dualathlon.random (ppp-217-133-42-200.cust-adsl.tiscali.it [217.133.42.200]) by dsl2.external.hp.com (Postfix) with ESMTP id 8EB3348AA for ; Thu, 8 Apr 2004 12:42:47 -0600 (MDT) Date: Thu, 8 Apr 2004 20:42:45 +0200 From: Andrea Arcangeli To: James Bottomley Subject: Re: [parisc-linux] rmap: parisc __flush_dcache_page Message-ID: <20040408184245.GO31667@dualathlon.random> References: <20040408153412.GD31667@dualathlon.random> <1081439244.2165.236.camel@mulgrave> <20040408161610.GF31667@dualathlon.random> <1081441791.2105.295.camel@mulgrave> <20040408171017.GJ31667@dualathlon.random> <1081446226.2105.402.camel@mulgrave> <20040408175158.GK31667@dualathlon.random> <1081447654.1885.430.camel@mulgrave> <20040408181838.GN31667@dualathlon.random> <1081448897.2105.465.camel@mulgrave> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1081448897.2105.465.camel@mulgrave> Cc: Hugh Dickins , Linux Kernel , parisc-linux@parisc-linux.org List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Apr 08, 2004 at 01:28:17PM -0500, James Bottomley wrote: > So you're worried about our code? OK, if you look, you'll see we only > have to flush one address in the mmap_shared list, (which is usually the > long list). if you need to flush just one address, the prio-tree may give you an huge boost, overall flush_dcache_page should become pretty quick in most situations. > I'd be very surprised if flush_dcache_page executes more than a few > hundred instructions all told...that's certainly nowhere close to a > timeslice. What you miss is that the problem is not in flush_dcache_page, the problem is that the _other_ users of the prio-tree may take as long as a timeslice. So it's the _other_ user that you've no control about (i.e. truncate) that may take timeslices with irq disabled. But I've an fairly optimal solution for you, you should make it a read_write spinlock, with the readers not disabling interrupts, and the writer disabling interrupts, the writer of the prio-tree will not take a timeslice, the readers instead will take a timeslice, but since they're readers and you've only to read in the flush_dcache_page irq context, you don't need to disable irqs for the readers. I don't have better solutions than this one at the moment (yeah there's the rcu reading of the prio-tree but I'd leave it for later...)