Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 24 Apr 2017 20:30:19 -0700 | Subject | Re: [PATCH RFC v6] x86,mm,sched: make lazy TLB mode even lazier |
| |
On Fri, Sep 9, 2016 at 12:44 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Thu, Sep 08, 2016 at 09:39:45PM -0700, Andy Lutomirski wrote: >> If they're busy threads, shouldn't the yield return immediately >> because the threads are still ready to run? Lazy TLB won't do much >> unless you get the kernel in some state where it's running in the >> context of a different kernel thread and hasn't switched to >> swapper_pg_dir. IIRC idle works like that, but you'd need to actually >> sleep to go idle. > > Right, a task doing: > > for (;;) sched_yield(); > > esp. when its the only runnable thread on the CPU, is a busy thread. It > will not enter switch_mm(), which was where the invalidate hook was > placed IIRC.
Hi all-
I'm guessing that this patch got abandoned, at least temporarily. I'm currently polishing up my PCID series, and I think it might be worth revisiting this on top of my PCID rework. The relevant major infrastructure change I'm making with my PCID code is that I'm adding an atomic64_t to each mm_context_t that gets incremented every time a flush on that mm is requested. With that change, we might be able to get away with simply removing a cpu from mm_cpumask immediately when it enters lazy mode and adding a hook to the scheduler to revalidate the TLB state when switching mms when we were previously lazy. Revalidation would just check that the counter hasn't changed.
--Andy
| |