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. 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
