[RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting
Nicholas Piggin
npiggin at gmail.com
Fri Dec 4 18:54:40 AEDT 2020
Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm:
> This is a mockup. It's designed to illustrate the algorithm and how the
> code might be structured. There are several things blatantly wrong with
> it:
>
> The coding stype is not up to kernel standards. I have prototypes in the
> wrong places and other hacks.
>
> There's a problem with mm_cpumask() not being reliable.
Interesting, this might be a way to reduce those IPIs with fairly
minimal fast path cost. Would be interesting to see how much performance
advantage it has over my dumb simple shoot-lazies.
For powerpc I don't think we'd be inclined to go that way, so don't feel
the need to add this complexity for us alone -- we'd be more inclined to
move the exit lazy to the final TLB shootdown path, which we're slowly
getting more infrastructure in place to do.
(The powerpc hash MMU code which we're slowly moving away from might
never get that capability because it's complex there and hard to do with
that virtualisation model so current big systems (and radix MMU until we
finish the TLB flushing stuff) want something here, but for those the
shoot-lazies could quite likely be sufficient)
But if core code was moved over to something like this for the benefit of
others archs we'd probably just as happily do that.
There's a few nits but I don't think I can see a fundamental problem
yet.
Thanks,
Nick
More information about the Linuxppc-dev
mailing list