[lkml]   [2011]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [PATCH 06/17] arm: mmu_gather rework
    On Tue, 2011-03-01 at 17:05 -0500, Chris Metcalf wrote:

    > For Tile, the concern is that we want to make sure to invalidate the
    > i-cache. The I-TLB is handled by the regular TLB flush just fine, like the
    > other architectures. So our concern is that once we have cleared the page
    > table entries and invalidated the TLBs, we still have to deal with i-cache
    > lines in any core that may have run code from that page. The risk is that
    > the kernel might free, reallocate, and then run code from one of those
    > pages, all before the stale i-cache lines happened to be evicted.

    From reading Documentation/cachetlb.txt, update_mmu_cache() can be used
    to flush i-cache whenever you install a pte with executable permissions,
    and covers the particular case you mention above.

    DaveM any comment? You seem to be the one who wrote that document :-)

    > The current Tile code flushes the icache explicitly at two different times:
    > 1. Whenever we flush the TLB, since this is one time when we know who might
    > currently be using the page (via cpu_vm_mask) and we can flush all of them
    > easily, piggybacking on the infrastructure we use to flush remote TLBs.
    > 2. Whenever we context switch, to handle the case where cpu 1 is running
    > process A, then switches to B, but another cpu still running process A
    > unmaps an executable page that was in cpu 1's icache. This way when cpu 1
    > switches back to A, it doesn't have to worry about any unmaps that occurred
    > while it was switched out.
    > > I'm not sure what we can do about TILE's VM_HUGETLB usage though, if it
    > > needs explicit flushes for huge ptes it might just have to issue
    > > multiple tlb invalidates and do them from tlb_start_vma()/tlb_end_vma().
    > I'm not too concerned about this. We can make the flush code check both
    > page sizes at a small cost in efficiency, relative to the overall cost of
    > global TLB invalidation.

    OK, that's basically what I made it do now:

    Index: linux-2.6/arch/tile/kernel/tlb.c
    --- linux-2.6.orig/arch/tile/kernel/tlb.c
    +++ linux-2.6/arch/tile/kernel/tlb.c
    @@ -64,14 +64,13 @@ void flush_tlb_page(const struct vm_area

    -void flush_tlb_range(const struct vm_area_struct *vma,
    +void flush_tlb_range(const struct mm_struct *mm,
    unsigned long start, unsigned long end)
    - unsigned long size = hv_page_size(vma);
    - struct mm_struct *mm = vma->vm_mm;
    - int cache = (vma->vm_flags & VM_EXEC) ? HV_FLUSH_EVICT_L1I : 0;
    - flush_remote(0, cache, &mm->cpu_vm_mask, start, end - start, size,
    - &mm->cpu_vm_mask, NULL, 0);
    + flush_remote(0, HV_FLUSH_EVICT_L1I, &mm->cpu_vm_mask,
    + start, end - start, PAGE_SIZE, &mm->cpu_vm_mask, NULL, 0);
    + flush_remote(0, 0, &mm->cpu_vm_mask,
    + start, end - start, HPAGE_SIZE, &mm->cpu_vm_mask, NULL, 0);

    And I guess that if the update_mmu_cache() thing works out we can remove
    the HV_FLUSH_EVICT_L1I thing.

     \ /
      Last update: 2011-03-02 11:55    [W:0.023 / U:0.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site