lkml.org 
[lkml]   [2014]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86,mm: delay TLB flush after clearing accessed bit

* Rik van Riel <riel@redhat.com> wrote:

> >> int ptep_clear_flush_young(struct vm_area_struct *vma,
> >> unsigned long address, pte_t *ptep)
> >> {
> >> - int young;
> >> + int young, cpu;
> >>
> >> young = ptep_test_and_clear_young(vma, address, ptep);
> >> - if (young)
> >> - flush_tlb_page(vma, address);
> >> + if (young) {
> >> + for_each_cpu(cpu, vma->vm_mm->cpu_vm_mask_var)
> >> + tlb_set_force_flush(cpu);
> >
> > Hm, just to play the devil's advocate - what happens when we have
> > a va that is used on a few dozen, a few hundred or a few thousand
> > CPUs? Will the savings be dwarved by the O(nr_cpus_used) loop
> > overhead?
> >
> > Especially as this is touching cachelines on other CPUs and likely
> > creating the worst kind of cachemisses. That can really kill
> > performance.
>
> flush_tlb_page does the same O(nr_cpus_used) loop, but it sends an
> IPI to each CPU every time, instead of dirtying a cache line once
> per pageout run (or until the next context switch).
>
> Does that address your concern?

That depends on the platform - which could implement flush_tlb_page()
as a broadcast IPI - but yes, it was bad before as well, now it became
more visible and I noticed it :)

Wouldn't it be more scalable to use a generation count as a timestamp,
and set that in the mm? mm that last flushed before that timestamp
need to flush, or so. That gets rid of the mask logic and the loop,
AFAICS.

Thanks,

Ingo


\
 
 \ /
  Last update: 2014-04-01 16:02    [W:0.764 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site