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
