[Top] [All Lists]

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

To: Leonid Yegoshin <>
Subject: Re: [PATCH V2 1/3] MIPS: Fix cache flushing for swap pages with non-DMA I/O.
From: "Maciej W. Rozycki" <>
Date: Tue, 24 Feb 2015 21:51:03 +0000 (GMT)
Cc: Zenon Fortuna <>, "Steven J. Hill" <>, IMG - MIPS Linux Kernel developers <>, Linux MIPS Mailing List <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <>
User-agent: Alpine 2.11 (LFD 23 2013-08-11)
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.


<Prev in Thread] Current Thread [Next in Thread>