Re: [PATCH V2 1/3] MIPS: Fix cache flushing for swap pages with non-DMA I/O.

[Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>]

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