Date: Wed, 16 Oct 2013 20:18:16 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: Re: why does /dev/md call cpu_dcache_flush()? Message-ID: <94783.1381954696@critter.freebsd.dk> In-Reply-To: <1381953459.1168.48.camel@revolution.hippie.lan> References: <1381953459.1168.48.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94783.1381954696>