[Top] [All Lists]

Re: cacheflush system call-MIPS

To: Ralf Baechle <>
Subject: Re: cacheflush system call-MIPS
From: peter fuerst <>
Date: Sat, 14 Feb 2009 00:50:46 +0100 (CET)
Cc: naresh kamboju <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>

Hi Ralf,

there is one more good reason to ... : the Impact Xserver needs to do
a cacheflush(a,w,DCACHE) as part of the refresh-sequence.
And hence requires a sys_cacheflush, let's say, more conforming to the
man-page (or some disgusting new ioctl in the Impact kernel-driver to
do an equivalent operation ;-)

kind regards :-)

On Wed, 11 Feb 2009, Ralf Baechle wrote:

> Date: Wed, 11 Feb 2009 13:16:49 +0000
> From: Ralf Baechle <>
> To: naresh kamboju <>
> Cc:
> Subject: Re: cacheflush system call-MIPS
> On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote:
> > Hi Mr. Ralf,
> >
> > I have tried to test cacheflush system call to generate EINVAL
> >
> > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel.
> >
> > I have referred latest Man pages there is a bug column.
> >
> > Please let me know whether this is bug in source code or in the man page.
> >
> > (arch/mips/mm/cache.c)
> The answer is probably a bit of both.  The API and error behaviour was
> defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier.
> Gcc relies on the existence of this syscall - or rather a library
> function which usually will be implemented to execute this syscall because
> the operating requires kernel priviledges - so Linux had to get an
> implementation as well.
> Now in practice there is only one good reason to perform explicit
> cacheflushes from userspace and that's to ensure I-cache coherency and
> that's the one thing the Linux implementation of cacheflush(2) is trying
> to do.  Therefore the implementation ignores the cache argument and
> will instead perform whatever is necessary to guarantee I-cache coherency -
> whatever this means on a particlar implementation.
> Similarly the implementation won't verify that every byte of the range
> is accessible.  For a large range it instead may choose to perform a full
> writeback / invalidation of some or all parts of the cache hierarchy
> which might mean there will not be an error return even though part of
> the address space may not be accessible.
> Talking about bugs - the "BUGS" section of the man page is wrong.  A full
> cacheflush is only performed if this is considered to be faster than a
> cacheline-by-cacheline flush.
>   Ralf

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