On 02/24/2015 01:51 PM, Maciej W. Rozycki wrote:
On Tue, 24 Feb 2015, Leonid Yegoshin wrote:
It absolutely has to work, on the MIPS target GCC emits code invoking it
to synchronise trampolines built at the run time on the stack (used for
calling nested functions, a C language extension borrowed from Pascal,
etc.), before passing execution there. Verification of this syscall is
probably implicitly covered by the GCC test suite already.
Maciej
cacheflush() syscall traps into kernel and it executes I and D caches
flushing.
However, it's implementation in 'master' branch from Linus tree is wrong: if
you call it in multicore environment for size > L1 cache size then it does it
incorrectly: doesn't call IPI for index cacheops.
The correct way is ... sorry, can't find it in LMO...
Hmm, on SMP using hit operations for cacheflush(2) that rely on the
hardware cache coherency protocol should be cheaper up to at least the
size of the cache times the number of processors. To say nothing of the
the overhead of sending and receiving IPIs.
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.
Especially taking into account TLB exceptions and postprocessing in
fixup_exception() for swapped-out/not-yet-loaded-ELF blocks.
- Leonid.
It's not like using cacheflush(2) for
large blocks is that common. And GCC trampolines consist of a couple of
instructions only, they'll never hit the problem.
Maciej
