Thread (10 messages) flat view 10 messages, 4 authors, 2021-11-05

Re: flush_dcache_page vs kunmap_local

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2021-11-04 15:31:19
Also in: lkml

On Thu, Nov 4, 2021 at 8:03 AM Matthew Wilcox [off-list ref] wrote:
Linus offers the opinion that kunmap calls should imply a
flush_dcache_page().  Christoph added calls to flush_dcache_page()
in commit 8dad53a11f8d.  Was this "voodoo programming", or was there
a real problem being addressed?
I don't think anybody actually uses/cares about flush_dcache_page() at
all, and pretty much all uses are random and voodoo.

No sane architecture uses pure virtual caches, and the insane ones
haven't been an issue for a long time either.

But if there are still systems with pure virtual caches, and they need
manual cache flushing, then I do think that kunmap is one of the
points that needs it, since that's the "I'm done accessing this data
through this virtual address" place.

End result: I really don't think anybody cares any more (and only
truly broken architectures ever did). I'd personally be perfectly
happy just saying "we might as well drop support for non-coherent
caches entirely".

But as long as we have those random odd "flush dcache manually"
things, I think kunmap() is one of the places that probably should
continue to do them.

Of course, the kunmap case is _doubly_ irrelevant, because we should
certainly hope that not only are those noncoherent pure virtual caches
a thing of the past, highmem itself should be going away.

Why did this come up? Do you actually have some hardware or situation
that cares?

                   Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help