[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zll2ILUNWE-JPi9U@linux.dev>
Date: Fri, 31 May 2024 00:02:56 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Yu Zhao <yuzhao@...gle.com>
Cc: James Houghton <jthoughton@...gle.com>,
Sean Christopherson <seanjc@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Albert Ou <aou@...s.berkeley.edu>,
Ankit Agrawal <ankita@...dia.com>, Anup Patel <anup@...infault.org>,
Atish Patra <atishp@...shpatra.org>,
Axel Rasmussen <axelrasmussen@...gle.com>,
Bibo Mao <maobibo@...ngson.cn>,
Catalin Marinas <catalin.marinas@....com>,
David Matlack <dmatlack@...gle.com>,
David Rientjes <rientjes@...gle.com>,
Huacai Chen <chenhuacai@...nel.org>,
James Morse <james.morse@....com>, Jonathan Corbet <corbet@....net>,
Marc Zyngier <maz@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Raghavendra Rao Ananta <rananta@...gle.com>,
Ryan Roberts <ryan.roberts@....com>,
Shaoqin Huang <shahuang@...hat.com>, Shuah Khan <shuah@...nel.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Tianrui Zhao <zhaotianrui@...ngson.cn>,
Will Deacon <will@...nel.org>, Zenghui Yu <yuzenghui@...wei.com>,
kvm-riscv@...ts.infradead.org, kvm@...r.kernel.org,
kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-mips@...r.kernel.org,
linux-mm@...ck.org, linux-riscv@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev
Subject: Re: [PATCH v4 2/7] mm: multi-gen LRU: Have secondary MMUs
participate in aging
On Fri, May 31, 2024 at 12:05:48AM -0600, Yu Zhao wrote:
[...]
> All optimizations in v2 were measured step by step. Even that bitmap,
> which might be considered overengineered, brought a readily
> measuarable 4% improvement in memcached throughput on Altra Max
> swapping to Optane:
That's great, but taking an iterative approach to the problem allows
the reviewers and maintainers to come to their own conclusions about
each optimization independently. Squashing all of that together and
posting the result doesn't allow for this.
Even if we were to take the series as-is, the door is wide open to
subsequent improvements.
> What I don't think is acceptable is simplifying those optimizations
> out without documenting your justifications (I would even call it a
> design change, rather than simplification, from v3 to v4).
No, sorry, there's nothing wrong with James' approach here.
The discussion that led to the design of v4 happened on list; you were
on CC. The general consensus on the KVM side was that the bitmap was
complicated and lacked independent justification. There was ample
opportunity to voice your concerns before he spent the time on v4.
You seriously cannot fault a contributor for respinning their work based
on the provided feedback.
--
Thanks,
Oliver
Powered by blists - more mailing lists