[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1607141044.0ibmnpwoeq.astroid@bobo.none>
Date: Sat, 05 Dec 2020 14:49:04 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Anton Blanchard <anton@...abs.org>, Arnd Bergmann <arnd@...db.de>,
Catalin Marinas <catalin.marinas@....com>,
Dave Hansen <dave.hansen@...el.com>,
Jann Horn <jannh@...gle.com>,
linux-arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Andy Lutomirski <luto@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Nadav Amit <nadav.amit@...il.com>,
Rik van Riel <riel@...riel.com>,
Will Deacon <will@...nel.org>, X86 ML <x86@...nel.org>
Subject: Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting
Excerpts from Andy Lutomirski's message of December 5, 2020 12:37 am:
>
>
>> On Dec 3, 2020, at 11:54 PM, Nicholas Piggin <npiggin@...il.com> wrote:
>>
>> 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.
>
> My real motivation isn’t really performance per se. I think there’s considerable value in keeping the core algorithms the same across all architectures, and I think my approach can manage that with only a single hint from the architecture as to which CPUs to scan.
>
> With shoot-lazies, in contrast, enabling it everywhere would either malfunction or have very poor performance or even DoS issues on arches like arm64 and s390x that don’t track mm_cpumask at all. I’m sure we could come up with some way to mitigate that, but I think that my approach may be better overall for keeping the core code uniform and relatively straightforward.
I'd go the other way. The mm_cpumark, TLB, and lazy maintainence is
different between architectures anyway. I'd keep the simple refcount,
and the pretty simple shoot-lazies approaches for now at least until
a bit more is done on other fronts. If x86 is shooting down lazies on
the final TLB flush as well, then I might be inclined to think that's
the better way to go in the long term. Shoot-lazies would be a bit of
a bolted on hack for powerpc/hash but it has ~zero impact to core code
really.
Thanks,
Nick
Powered by blists - more mailing lists