cacheflush system call-MIPS

cacheflush system call-MIPS

[naresh kamboju]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 411 bytes --]

Re: cacheflush system call-MIPS

[Ralf Baechle]

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

Re: cacheflush system call-MIPS

[peter fuerst]

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 <ralf@linux-mips.org>
> To: naresh kamboju <naresh.kernel@gmail.com>
> Cc: linux-mips@linux-mips.org
> 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
>
>

Re: cacheflush system call-MIPS

[Ralf Baechle]

On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote:

> 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 ;-)

Why does it need that flush?

  Ralf

Re: cacheflush system call-MIPS

[peter fuerst]

> 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
> From: Ralf Baechle <ralf@linux-mips.org>
> To: peter fuerst <post@pfrst.de>
> Cc: naresh kamboju <naresh.kernel@gmail.com>, linux-mips@linux-mips.org
> Subject: Re: cacheflush system call-MIPS
>
> On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote:
>
> > 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 ;-)
>
> Why does it need that flush?
>
>   Ralf
>
>

Re: cacheflush system call-MIPS

[David Daney]

peter fuerst wrote:
>> Why does it need that flush?
> 
> 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



> kind regards
> 
> 
> 
> On Fri, 13 Feb 2009, Ralf Baechle wrote:
> 
>> Date: Fri, 13 Feb 2009 23:56:03 +0000
>> From: Ralf Baechle <ralf@linux-mips.org>
>> To: peter fuerst <post@pfrst.de>
>> Cc: naresh kamboju <naresh.kernel@gmail.com>, linux-mips@linux-mips.org
>> Subject: Re: cacheflush system call-MIPS
>>
>> On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote:
>>
>>> 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 ;-)
>> Why does it need that flush?
>>
>>   Ralf
>>
>>
> 
> 

Re: cacheflush system call-MIPS

[Eugene Surovegin]

On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote:
> peter fuerst wrote:
>>> Why does it need that flush?
>> 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.

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

RE: cacheflush system call-MIPS

[David VomLehn (dvomlehn)]

> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Eugene 
> Surovegin
> Sent: Tuesday, February 17, 2009 11:45 AM
> To: David Daney
> Cc: post@pfrst.de; Ralf Baechle; linux-mips@linux-mips.org
> Subject: Re: cacheflush system call-MIPS
> 
> On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote:
> > peter fuerst wrote:
> >>> Why does it need that flush?
> >> 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.
> 
> 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.

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.

RE: cacheflush system call-MIPS

[David VomLehn (dvomlehn)]

> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Eugene 
> Surovegin
> Sent: Tuesday, February 17, 2009 11:45 AM
> To: David Daney
> Cc: post@pfrst.de; Ralf Baechle; linux-mips@linux-mips.org
> Subject: Re: cacheflush system call-MIPS
> 
> On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote:
> > peter fuerst wrote:
> >>> Why does it need that flush?
> >> 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.
> 
> 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.

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.