Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Oct 09, 2013 at 08:53:20AM +0200, Krzysztof Hałasa wrote:

> > 16K is a silver bullet solution to all cache aliasing problems.  So if
> > your issue persists with 16K page size, it's not a cache aliasing issue.
> > Aside there are generally performance gains from the bigger page size.
> 
> I wonder why isn't the issue present in other cases. Perhaps remapping
> of a userspace address and accessing it with kseg0 isn't a frequent
> operation.
> 
> Shouldn't we change the default page size (on affected CPUs) to 16 KB
> then? Alternatively, we could flush/invalidate the cache when needed -
> is it a viable option?

The kernel is supposed to perform the necessary cache flushing, so any
remaining aliasing issue would be considered a bug.  But the code is
performance sensitive, some of the problem cases are twisted and complex
so bugs and unsolved corner cases show up every now and then.

The historic default is 4K page size - on some processors such as the
venerable R3000 it's also the only page size available.  Some application
code wants to know the page size and has wisely hardcoded 4K.  Also
a "fix" to binutils many years ago reduced the alignment of generated
binaries so they'd not run on a kernel with larger page size.  The
kernel configuration defaults are chosen to just work out of the box,
and 4K page size is the safest choice.

Anyway, binutils got "unfixed" again years ago so chances are 16K
will just work.

Does it work for you, even solve your problem?

  Ralf