From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3460D80BF8; Fri, 31 May 2024 07:03:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717138994; cv=none; b=E7vpO7fFVyAjfm/dcJG4fuVXX0k9iuUQBsyhthfbcakvzSzMYtA/m0okIqkKDBNa938CTOQdTnnhUb4WbsCc5+5p0Ac3c2DFr7m/1z7J9cwRLhH6uq/KcPdSC4PF6xFVfkW0Xjgt5AwzgKyVj3CFp6Zg44+iEm7po3lgXa0fRVs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717138994; c=relaxed/simple; bh=ci4Dj9A4R7c3SOWLTD2vJUP3/jPFngRAnm03r3E1GYQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Jta8ZffWVG5T5gqDUMWdON2kaMn047cXWMIeWY+/fHMNUjVY+vZJ+ei8ynqtrBzT/8dPSgi1kK5YrZtxaNeuVPojhpVXOVj1DfbL7yT8efPjLK1gp6C8mRzqjlYuVCif4w2dcakYSonSGzlUynVU+aVPfZwutk8BBx2paVOtb8Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=o0DHBTng; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="o0DHBTng" X-Envelope-To: yuzhao@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1717138989; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=d2FOFsODXea2tbyL8aZD5XgmjgnWiDeEr9B1wNurnWA=; b=o0DHBTng4ZOfOuLPBmuUfGnVx3C/mCiuligouG4hr+A2usMgep5pVaKau5drtUXhfEyIMO t3GiWpR9A6MCmp5eyKFnNs5t3R9y4lyGtWM/ea5I3xB4nMIOdla7XklCl1bqpY8yR0z7s8 SKfEnl7I0/BFWAoSHps846Lw14bj3Fs= X-Envelope-To: jthoughton@google.com X-Envelope-To: seanjc@google.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: pbonzini@redhat.com X-Envelope-To: aou@eecs.berkeley.edu X-Envelope-To: ankita@nvidia.com X-Envelope-To: anup@brainfault.org X-Envelope-To: atishp@atishpatra.org X-Envelope-To: axelrasmussen@google.com X-Envelope-To: maobibo@loongson.cn X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: dmatlack@google.com X-Envelope-To: rientjes@google.com X-Envelope-To: chenhuacai@kernel.org X-Envelope-To: james.morse@arm.com X-Envelope-To: corbet@lwn.net X-Envelope-To: maz@kernel.org X-Envelope-To: mpe@ellerman.id.au X-Envelope-To: npiggin@gmail.com X-Envelope-To: palmer@dabbelt.com X-Envelope-To: paul.walmsley@sifive.com X-Envelope-To: rananta@google.com X-Envelope-To: ryan.roberts@arm.com X-Envelope-To: shahuang@redhat.com X-Envelope-To: shuah@kernel.org X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: zhaotianrui@loongson.cn X-Envelope-To: will@kernel.org X-Envelope-To: yuzenghui@huawei.com X-Envelope-To: kvm-riscv@lists.infradead.org X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linux-doc@vger.kernel.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-kselftest@vger.kernel.org X-Envelope-To: linux-mips@vger.kernel.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-riscv@lists.infradead.org X-Envelope-To: linuxppc-dev@lists.ozlabs.org X-Envelope-To: loongarch@lists.linux.dev Date: Fri, 31 May 2024 00:02:56 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Yu Zhao Cc: James Houghton , Sean Christopherson , Andrew Morton , Paolo Bonzini , Albert Ou , Ankit Agrawal , Anup Patel , Atish Patra , Axel Rasmussen , Bibo Mao , Catalin Marinas , David Matlack , David Rientjes , Huacai Chen , James Morse , Jonathan Corbet , Marc Zyngier , Michael Ellerman , Nicholas Piggin , Palmer Dabbelt , Paul Walmsley , Raghavendra Rao Ananta , Ryan Roberts , Shaoqin Huang , Shuah Khan , Suzuki K Poulose , Tianrui Zhao , Will Deacon , Zenghui Yu , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev Subject: Re: [PATCH v4 2/7] mm: multi-gen LRU: Have secondary MMUs participate in aging Message-ID: References: <20240529180510.2295118-1-jthoughton@google.com> <20240529180510.2295118-3-jthoughton@google.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT 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