From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 990EB3D301A for ; Thu, 9 Apr 2026 17:03:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754206; cv=none; b=cNN35i3MuYT/R+95OtddkGUosYP7wx0fNDdRLRB8WkkOtYbtt9D1Hwlb9xEPMRCoPIh5/NRyOtqgxoRMngfRXhb6tkWAOGfVw+A3ThxdMxfO27tA1nOSgrLJkrOsLj/bmYVLcROBGXnRFHgqbi+9QeSezuP5EGTIN7rELIDZOmw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754206; c=relaxed/simple; bh=hrEHTDnl3dwFFDsB5g1X84DQzBVgUzXMnqTtztYZrHI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GP17BY7spxvW4fijn4jeefVVMFdVMw9k1QQcmkKSn7YcYHxj7jdeQQGwWJHptfHr9xBIf49RPYsAZXUfJMuy+rl9plyKGM9sAhPy+9UiYW3OSmHZjwSn9omtz0ZSXknJTFB93mJMFfGA8PISJ8pWtnF4Yd78495B/Zq1M6fAUkI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MsgRYGGt; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MsgRYGGt" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2aaf43014d0so7515805ad.2 for ; Thu, 09 Apr 2026 10:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775754205; x=1776359005; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VlbtUK11ejlh+AbZO79lglXrLZbQabCI4s+8sUt4k7s=; b=MsgRYGGtDnVOGi81FTUJe/bP7OztSxPIql+LXDS3NZ5BkWePK5nI2oKAjiyuixary7 Tuits+88dPTC1W5yLIKk5OaAvyRUHxvq5flVc7a981Lbi8bnaRCzYuCf/2U/8kjisqcX 1M2JRaHjgBkPyQl1Y5uBvy+i9d+Y3pqPbFztBZOxrLQ6Bn2ngj+nt812D7hPOkJ6h5l0 kN6d5fo2Xjmrxlpm95ooiqWkii2lWH2XeSfEnOiZ98oqN+icpJA4P77svSWL/g2cPNHc mhC0eXL4iIghrANPVi9MNCEsFqe/noMOfsRJTNgOOcMjQGQYcoIg9X1T+k8ZcXmAAZvP wvXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775754205; x=1776359005; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VlbtUK11ejlh+AbZO79lglXrLZbQabCI4s+8sUt4k7s=; b=ObIdeMhMMPm4ZF2rK4X1Luc9XBCMDvDgIGoqjAyMnJOev8fBbn1L37VKQkkHznEQzZ fnyzqVIwjzNmoSeSRQEBHBEkbMirt9/6PIv+OQ1gxEyE5YhcqwoeIP9ab3nrehwjep7J YKzCYdFF1Y0yDaI8GoaDimBnytWIMrkvxiq2TLNAhh9HNS0DKqLsjGgy18NIFg0VwoWC 0xx4dFOHbbXmisZWIBgRINT5LjI8wp9mDt64gRtE3b7G3FuUGYuAr62EWR8IHabkD9WY mTheLYUYDJuDkFl8HYJQbWnXN3vt/Cec/ARXuW32Z0SDCy7Xl32krP/85n6v0TpaJ0cY LikQ== X-Forwarded-Encrypted: i=1; AJvYcCUBLNQIttr36NHvfq4VvwVIrWQ4yn0GiTSeljiFpL5Nm0CjgML7gbYlQpeqPNKJM81nOncw1ETB8D3Vt/c=@vger.kernel.org X-Gm-Message-State: AOJu0YzGySes+GgCINjckQ652u19yzxxrTylZzeVVcmbqXGygaqPNqBw j0Y5PSF/bJx+gb1BAqkR4B9Q1CC08/EUPgjZ28c0YY3PqG4NK8KuutDO X-Gm-Gg: AeBDiesr2zarmpE7hAnWwI61T38Uf8VMSowRNyFGFBJLPOSnllY5ajqIespxLFn5Cyl NSvAHUag02icgBsFN4toF5to2KqKCwXY4MQCa9z6uaQT4FTFekOi5V66ckS3KGBTOIJ2uQfj9ID RkS14RZf7TfyV9d6bqRiA0oLG8Fux8/yUz65VngDgY/ccD+TdMQOA45QfqykFTh/OIxWR4j55UU IXcm5u/5a14C56re63EtQOTZYRuHgPdawS9laeAEqGTxv43hEvOGgqu4lcDOFTLXLZmcuX+BJrL qmDBSYE8rEGxK1YMXOl4duMYO2xMOQxPqWJ7RHSxdxwTx/bs1vBqbInMVYGHPJVLtEYWVtvr/I7 Elx7dwdTbTIwfGLH7R3DQweVxbgZVf9ZOoPm2UU4/a5utB01iSpYndKVuZvgb3EcFRdWg+SMi44 vHJkFJBacptWcXewXzngH15A9O88dcp5K2mg== X-Received: by 2002:a17:903:1ac3:b0:2b0:62dd:3a80 with SMTP id d9443c01a7336-2b281868e69mr284863465ad.17.1775754203306; Thu, 09 Apr 2026 10:03:23 -0700 (PDT) Received: from google.com ([118.150.148.19]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2d4f27048sm554505ad.62.2026.04.09.10.03.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 10:03:22 -0700 (PDT) Date: Fri, 10 Apr 2026 01:03:19 +0800 From: Kuan-Wei Chiu To: Joonwon Kang Cc: dennis@kernel.org, tj@kernel.org, cl@gentwo.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dodam@google.com Subject: Re: [PATCH v2] percpu: Fix hint invariant breakage Message-ID: References: <20260408100642.83919-1-joonwonkang@google.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <20260408100642.83919-1-joonwonkang@google.com> Hi Joonwon, On Wed, Apr 08, 2026 at 10:06:42AM +0000, Joonwon Kang wrote: > The invariant "scan_hint_start > contig_hint_start if and only if > scan_hint == contig_hint" should be kept for hint management. However, > it could be broken in some cases: > > - if (new contig == contig_hint == scan_hint) && (contig_hint_start < > scan_hint_start < new contig start) && the new contig is to become a > new contig_hint due to its better alignment, then scan_hint should > be invalidated instead of keeping the old value. > > - if (new contig == contig_hint > scan_hint) && (new contig start < > contig_hint_start) && the new contig is not to become a new > contig_hint, then scan_hint should be not updated to the new contig. > > This commit refactors the percpu block update code to make it more > visible on what to consider, e.g. when the new contig overlaps with the > old contig_hint or scan_hint, fixes the invariant breakage and also > optimizes scan_hint further. Some of the optimization cases when no > overlap occurs are: > > - if (new contig > contig_hint > scan_hint) && (scan_hint_start < new > contig start < contig_hint_start), then keep scan_hint instead of > invalidating it. > > - if (new contig > contig_hint == scan_hint) && (contig_hint_start < > new contig start < scan_hint_start), then update scan_hint to the > old contig_hint instead of invalidating it. > > - if (new contig == contig_hint > scan_hint) && (new contig start < > contig_hint_start) && the new contig is to become a new contig_hint > due to its better alignment, then update scan_hint to the old > contig_hint instead of invalidating or keeping it. > > Signed-off-by: Joonwon Kang > --- > v1 -> v2: Consider cases where the new contig overlaps with the existing > contig_hint or scan_hint. > > mm/percpu.c | 124 +++++++++++++++++++++++++++++++++++----------------- > 1 file changed, 85 insertions(+), 39 deletions(-) > Just a few minor style nits; checkpatch.pl reported the following: CHECK: Lines should not end with a '(' #173: FILE: mm/percpu.c:653: + overlap_with_contig_hint = pcpu_region_overlap( CHECK: Unnecessary parentheses around 'scan_hint_cand_2 > scan_hint_cand_1' #258: FILE: mm/percpu.c:699: + if ((scan_hint_cand_2 > scan_hint_cand_1) || + (scan_hint_cand_2 == scan_hint_cand_1 && + scan_hint_cand_2_start > scan_hint_cand_1_start)) { Since this patch will need a respin anyway, I think it would be better to address these together in the next version. Regards, Kuan-Wei