Only if you have a physical indexed cache. For a virtual indexed cache
the kernel will have to writeback and invalidate page M before return to
userland resulting in the new page being not in the cache.
Which may leave your caches pretty cold ...
> what about playing an MMU trick here: lets 'flip' the two identical pages,
> with page N being mapped into process X, page M mapped into the other
> processes' virtual memory. Thus we could get the 'hot and cached' page
> for the process that is just about to use that page.
>
> We have problems identifying 'the other processes', but maybe this could
> be done by processing vmarea->vm_inode->i_mmap, or if this is too slow, by
> implementing real physical to virtual mapping capabilities. [which could
> be used for other things too, based on a nice discussion with Mark
> Hemment]
This is definately a nice thing for virtual indexed caches which in many
cases (R4000: 75%) could make writeback/flushing of the cache unnecessary.
Luckily implementing that is relativly easy even without knowing the
entire virtual address because we can guess the required bits from the
page's index in the pte table.
> but if this all works, we could have hot cache for the process continuing
> execution, for the price of N*(cost of invlpg+cost of backmapping)+1,
> where N is the number of processes mapping the page. At least for small
> 'N' and for Intel caches this looks like a definit win ...
Intel caches == physical indexed. No idea how expensive invalidating
caches on Intel is but at least on some 68k and MIPS CPUs this can become
pretty expensive.
Ralf