From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755125Ab0CDPfg (ORCPT ); Thu, 4 Mar 2010 10:35:36 -0500 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:57739 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755074Ab0CDPfe (ORCPT ); Thu, 4 Mar 2010 10:35:34 -0500 Date: Thu, 4 Mar 2010 15:34:10 +0000 From: Russell King - ARM Linux To: Catalin Marinas Cc: James Bottomley , Pavel Machek , FUJITA Tomonori , benh@kernel.crashing.org, mdharm-kernel@one-eyed-alien.net, linux-usb@vger.kernel.org, x0082077@ti.com, sshtylyov@ru.mvista.com, tom.leiming@gmail.com, bigeasy@linutronix.de, oliver@neukum.org, linux-kernel@vger.kernel.org, santosh.shilimkar@ti.com, greg@kroah.com, linux-arm-kernel@lists.infradead.org Subject: Re: USB mass storage and ARM cache coherency Message-ID: <20100304153410.GC6622@n2100.arm.linux.org.uk> References: <1267316072.23523.1842.camel@pasglop> <1267333263.2762.11.camel@mulgrave.site> <20100302211049V.fujita.tomonori@lab.ntt.co.jp> <1267549527.15401.78.camel@e102109-lin.cambridge.arm.com> <20100303215437.GF2579@ucw.cz> <1267709756.6526.380.camel@e102109-lin.cambridge.arm.com> <20100304135128.GA12191@atrey.karlin.mff.cuni.cz> <1267712512.31654.176.camel@mulgrave.site> <20100304142704.GB6622@n2100.arm.linux.org.uk> <1267716323.6526.479.camel@e102109-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1267716323.6526.479.camel@e102109-lin.cambridge.arm.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 04, 2010 at 03:25:23PM +0000, Catalin Marinas wrote: > On Thu, 2010-03-04 at 14:27 +0000, Russell King - ARM Linux wrote: > > On Thu, Mar 04, 2010 at 07:51:52PM +0530, James Bottomley wrote: > > > On Thu, 2010-03-04 at 14:51 +0100, Pavel Machek wrote: > > > > Seems like ARM has requirement other architectures do not, that is > > > > a) not documented anywhere > > > > b) causes problems > > > > > > > > You could argue that performance improvement (how big is it, anyway?) > > > > is worth it, but this should be agreed to by wider community... > > > > > > Performance is always worth it provided we don't sacrifice correctness. > > > The thing which was discovered in this thread is basically that ARM is > > > handling deferred flushing (for D/I coherency) in a slightly different > > > way from everyone else ... once that's fixed, ARM will likely not have > > > the D/I problem, but we'll still have the libata (and other PIO systems) > > > D flushing issue. > > > > I think you've got that backwards. > > > > Reversing the meaning of PG_arch_1 will probably fix the D aliasing issue - > > since we'll interpret '0' to mean "page is dirty, it needs flushing before > > hitting userspace", whereas '1' means "page has been cleaned; there are no > > aliases." > > > > This doesn not address the I/D coherency issue, where the Icache needs > > attention to get rid of speculatively loaded cache lines while old data > > was present in the cache. > > The I-cache flushing is already handled in update_mmu_cache (or > set_pte_at in a future patch; I'm not talking about other issues on > ARM11MPCore here). You may not have been; my message was addressed to James to correct his message, which seems to have the issues confused.