On 02/24/2015 03:19 PM, Leonid Yegoshin wrote:
On 02/24/2015 02:57 PM, David Daney wrote:
On 02/24/2015 02:50 PM, Maciej W. Rozycki wrote:
On Tue, 24 Feb 2015, Leonid Yegoshin wrote:
For simplicity perhaps on SMP we should just always use hit
operations
regardless of the size requested.
High performance folks may not like doing a lot of stuff for 8MB VMA
release
instead of flushing 64KB.
What kind of a use case is that, what does it do?
Especially taking into account TLB exceptions and postprocessing in
fixup_exception() for swapped-out/not-yet-loaded-ELF blocks.
The normal use for cacheflush(2) I know of is for self-modifying or
other
run-time-generated code, to synchronise caches after a block of machine
code has been patched in -- SYNCI can also be used for that purpose
these
days,
SYNCI is only useful in non-SMP kernels.
Yes, until MIPS R6. I pressed hard on Arch team to change vague words in
SYNCI description and now (MIPS R6) it has words requiring execution on
all cores:
"SYNCI globalization:
Release 6: SYNCI globalization (as described below) is required:
compliant implementations must globalize SYNCI.
Portable software can rely on this behavior, and use SYNCI rather than
expensive “instruction cache shootdown”
using inter-processor interrupts."
Wow. I guess implementing -msynci wasn't a complete waste of time after
all.
In any event, it is irrelevant with respect to the semantics of
cacheflush(2), which still must be properly implemented.
David Daney
