Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
Date:   Wed, 2 Dec 2020 06:38:12 -0800
Message-Id: <BA2FB4C0-55EA-481A-824C-95B94EA29FAB@amacapital.net>
References: <20201202141957.GJ3021@hirez.programming.kicks-ass.net>
Cc:     Nicholas Piggin <npiggin@gmail.com>, linux-kernel@vger.kernel.org,
        x86@kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Arnd Bergmann <arnd@arndb.de>, linux-arch@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
        Anton Blanchard <anton@ozlabs.org>
In-Reply-To: <20201202141957.GJ3021@hirez.programming.kicks-ass.net>
To:     Peter Zijlstra <peterz@infradead.org>
Precedence: bulk


> On Dec 2, 2020, at 6:20 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> =EF=BB=BFOn Sun, Nov 29, 2020 at 02:01:39AM +1000, Nicholas Piggin wrote:
>> +         * - A delayed freeing and RCU-like quiescing sequence based on
>> +         *   mm switching to avoid IPIs completely.
>=20
> That one's interesting too. so basically you want to count switch_mm()
> invocations on each CPU. Then, periodically snapshot the counter on each
> CPU, and when they've all changed, increment a global counter.
>=20
> Then, you snapshot the global counter and wait for it to increment
> (twice I think, the first increment might already be in progress).
>=20
> The only question here is what should drive this machinery.. the tick
> probably.
>=20
> This shouldn't be too hard to do I think.
>=20
> Something a little like so perhaps?

I don=E2=80=99t think this will work.  A CPU can go idle with lazy mm and no=
hz forever.  This could lead to unbounded memory use on a lightly loaded sys=
tem.