Re: [linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > That I'll teach me to copy code without fully understanding it! On further
 > investigation I think it is needed, but I'd be delighted to be proved
 > wrong.

Well, I'm really confusing about the code.  I think that the code sometimes
works, but totally wrong.

Let's clarify things and discuss.

    (1) When do we need to fixup?
    (2) How can we find corresponding mapping?
    (3) How can we fix?

Let's discuss one by one.

(1) When do we need to fixup?

When there is shared mapping which causes the alias (synonym).  We
handle it at the TLB miss handling, finding the page with flags
VM_WRITE and VM_SHARED.

In this case, there is possibility that the page is shared among
different virtual mappings (which may or may not the map of the same
process) and page causes aliases (same physical memory but different
cache lines).


(2) How can we find corresponding mapping which shares the physical page?

# Here is, my confusing point.  I don't think the sun4c implementation
# handles the cases correctly.

Suppose we have virtual memory mapping (say, VMA) of the process.  In
this case we scan VMA through "vm_next_share" link.  We need to tangle
the link only if VMA->vm_file !=0 (??is this correct??, anonymous
page?).

Following the link "vm_next_share", we scan through all the mapping of
the file, and find the coresspoinding mapping which shares same physical
memory.  We need to check vm_pgoff to find matching mapping.


(3) How can we fix?

There're some alternatives.
    (a) Flushing cache for the page and TLB which may point that physical
        page.  Then set the flag of matching mapping VM_WRITE|VM_SHARED
        even if it was not set, so that using this map will cause TLB miss, 
        and come this fixup routine.
	No PTE handling is required.

    (b) Make each PTEs uncache-able so that we don't cache any data.

Comments?  Thoughts?
--