Aliasing VIPT dcache / Page colouring

[Vineet Gupta]

Hi Michal,

I read thru your fantastic work on Page coloring

http://d3s.mff.cuni.cz/publications/download/hocko-sipew10.pdf

and slightly different one at

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.2260&rep=rep1&type=pdf

I had a few questions on your paper/code, which you could hopefully answer.

To give you some background, I maintain the Linux port to ARC cores (from Synopsys).  We have ARC700 core with VIPT, 4 way set associative, L1 dcache. With a PAGE_SIZE of 8k, dcache >= 64k can potentially suffer from VIPT aliasing (we don't have specific hardware assist). Kernel runs in untranslated address space, hence uses paddr as handle for r/w to page, which can potentially alias with a non congruent userspace mapping of page. Currently we work around by doing the needed preventive flushes in update_mmu_cache( ) and other hooks intended for this purpose (although adding kmap_atomic based mapping for @src in copy_user_highpage is still on my TODO list)

Regarding your paper/code I wanted to confirm my understanding that the scheme itself can't be used in general for VIPT aliasing issue (ignoring the intrusiveness to core VM, Linus detesting it ...). It seems to be targeted at large PIPT caches, primarily to help spread the cache access via coloring / bin hopping etc. Plus it relies on user space defining the hints. The file backed page mapping doesn't take the color allocation path at all so I can't see how it will work with VIPT at all. anon mappings cause pages allocation rightaway, breaking the lazy allocation paradigm.

Am I reading it correctly ?

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