[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 22:50:53 +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:

> >   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, but the syscall long predates the presence of this instruction in 
the architecture .

 I fail to see any other need to force data out of cache in a user program 
(apart from also the corner case of benchmarking cold caches, such as in 
Zenon's case, but there the performance of the preparatory cache 
invalidation does not really matter).  Why would you expect VM to have 
been swapped out or not loaded where data has just been written?  Why 
would you want to call cacheflush(2) for blocks of data that haven't been 


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