Subject: cacheflush system call-MIPS

From: naresh kamboju <[email-masked]>
Date: Tue, 10 Feb 2009 20:46:58 +0530

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)

Thanks & regards

Naresh Kamboju

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 11 Feb 2009 13:16:49 +0000

> Please let me know whether this is bug in source code or in the man page.

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

---

From: peter fuerst <[email-masked]>
Date: Sat, 14 Feb 2009 00:50:46 +0100 (CET)

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 <[email-masked]>
> To: naresh kamboju <[email-masked]>
> Cc: [email-masked]
> Subject: Re: cacheflush system call-MIPS
>

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Feb 2009 23:56:03 +0000

> do an equivalent operation ;-)

Why does it need that flush?

  Ralf

---

From: peter fuerst <[email-masked]>
Date: Sun, 15 Feb 2009 03:20:04 +0100 (CET)

> Why does it need that flush?

To prepare the update-area (in the Shadow-FB) for DMA to RE.

kind regards

On Fri, 13 Feb 2009, Ralf Baechle wrote:

> Date: Fri, 13 Feb 2009 23:56:03 +0000
> To: peter fuerst <[email-masked]>
> Cc: naresh kamboju <[email-masked]>, [email-masked]

---

From: David Daney <[email-masked]>
Date: Tue, 17 Feb 2009 09:06:32 -0800

> To prepare the update-area (in the Shadow-FB) for DMA to RE.

And on systems where the root frame buffer is directly manipulated by 
the CPU, the video system is continually using DMA to refresh the 
display.  A cache flush can be required to eliminate transient visual 
glitches.

David Daney

---

From: Eugene Surovegin <[email-masked]>
Date: Tue, 17 Feb 2009 11:45:09 -0800

On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote:
> And on systems where the root frame buffer is directly manipulated by the 
> CPU, the video system is continually using DMA to refresh the display.  A 
> cache flush can be required to eliminate transient visual glitches.

In this case using uncached fb access is the only way to avoid 
glitches - you cannot control cache line evictions. And it's usually 
faster to use uncached mappings for effectively write-only regions.

-- 
Eugene

---

From: "David VomLehn (dvomlehn)" <[email-masked]>
Date: Tue, 17 Feb 2009 15:50:41 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eugene 
> Surovegin
> Sent: Tuesday, February 17, 2009 11:45 AM
> To: David Daney
> Cc: [email-masked]; Ralf Baechle; [email-masked]

A far more appropriate caching mode for frame buffers, if your processor
supports it, is to use uncached accelerated
(_CACHED_UNCACHED_ACCELERATED in the kernel source). Unfortunately, at
least as far as I can tell, you'd need to write your own driver to do
the memory mapping so that it can set the cache coherency attributes to
get this behavior. Not especially hard if you are familiar with device
drivers, much harder if you are note.