From owner-freebsd-hackers@FreeBSD.ORG  Wed Oct 16 20:18:24 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 788118E6;
 Wed, 16 Oct 2013 20:18:24 +0000 (UTC)
 (envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
 by mx1.freebsd.org (Postfix) with ESMTP id 3BD42281D;
 Wed, 16 Oct 2013 20:18:24 +0000 (UTC)
Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2])
 by phk.freebsd.dk (Postfix) with ESMTP id 505553EB5F;
 Wed, 16 Oct 2013 20:18:17 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
 by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r9GKIG3Y094784;
 Wed, 16 Oct 2013 20:18:17 GMT (envelope-from phk@phk.freebsd.dk)
To: Ian Lepore <ian@FreeBSD.org>
Subject: Re: why does /dev/md call cpu_dcache_flush()?
In-reply-to: <1381953459.1168.48.camel@revolution.hippie.lan>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
References: <1381953459.1168.48.camel@revolution.hippie.lan>
Content-Type: text/plain; charset=ISO-8859-1
Date: Wed, 16 Oct 2013 20:18:16 +0000
Message-ID: <94783.1381954696@critter.freebsd.dk>
X-Mailman-Approved-At: Wed, 16 Oct 2013 20:56:54 +0000
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 20:18:24 -0000

In message <1381953459.1168.48.camel@revolution.hippie.lan>, Ian Lepore writes:
>The only caller of cpu_dcache_flush() in the entire system appears to be
>the md device.  Does anybody know why it makes the call?

r192323 | marcel | 2009-05-18 18:37:18 +0000 (Mon, 18 May 2009) | 20 lines

Add cpu_flush_dcache() for use after non-DMA based I/O so that a
possible future I-cache coherency operation can succeed. On ARM
for example the L1 cache can be (is) virtually mapped, which
means that any I/O that uses temporary mappings will not see the
I-cache made coherent. On ia64 a similar behaviour has been
observed. By flushing the D-cache, execution of binaries backed
by md(4) and/or NFS work reliably.
For Book-E (powerpc), execution over NFS exhibits SIGILL once in
a while as well, though cpu_flush_dcache() hasn't been implemented
yet.

Doing an explicit D-cache flush as part of the non-DMA based I/O
read operation eliminates the need to do it as part of the
I-cache coherency operation itself and as such avoids pessimizing
the DMA-based I/O read operations for which D-cache are already
flushed/invalidated. It also allows future optimizations whereby
the bcopy() followed by the D-cache flush can be integrated in a
single operation, which could be implemented using on-chips DMA
engines, by-passing the D-cache altogether.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.