lkml.org 
[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectCache aliasing
Date
I'm working on a port of Linux to a processor that has virutally
indexed caches that are larger than the page size. This brings up
the documented feature of cache aliasing.

As I am looking over how other ports (sh-4, sparc64 etc) have solved
the problem, it made me wonder if this is the best way to solve
the problem.

Would it make more sense to just always ensure that your
virtual and physical pages had matching "color" bits?

For example, in the memory allocator, you would have to pass in
the vaddr that you wanted to map to physical space, and then the
memory allocator would find a physical page of the correct color.

And in the case where you are mirroring a user page into kernel
space, you would have to choose a virtual address of the correct
colour. On architectures like x86 where cache aliasing is never
a concern, this code could be optimized away.


The benefits would be, any architecture that has cache aliasing
wouldn't have to go through hoops to keep memory coherent, and
depending on how often memory is flushed in the caches it might
give some performance boost.



-John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.053 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site