From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (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 25DD53101C0 for ; Wed, 13 May 2026 06:18:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778653093; cv=none; b=TOD6VuMXS/vXMbeQlQSYGsPxAdi1rKFcW9tPBtu/7y8hwKD2ZAWkMbt137JG6WxMau5XdDq3c7amL5tacIlj+Dpq6b8ls52YIwPIWDTIY+wI4Un6vgNb33+gjI/QBNI+AnoO8alxBOQD5i1EhVc//5zgX2uSpyhSkAxF5cix7ww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778653093; c=relaxed/simple; bh=2mddzn8FOv+9JE+ZEowJE9A+Pi+JnPeeCajzCnhFPcI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=rIM/hRtjvukeogsP8v2RSYDivdAMtr70DMmLLChfsHVdIfhQHoQbBd+A7J8nTXKnyKxO4MKAuhU+qMPoSrheWta7uZ80Ef9EmDSeJqyJGTHsv7BLJSqd5lhHBAu7elNyQ5rj/yAwyY2WwBaVQotTeuCm95iIxThxhMTeDGB8fDM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=lLPo6a1z; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lLPo6a1z" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c8294d8c48eso1804855a12.0 for ; Tue, 12 May 2026 23:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778653091; x=1779257891; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=TX9DcXAmoIgsu4IRPsBLLucku/osUjEAMFhUMNrAFrU=; b=lLPo6a1zV9p3cI9n1wG7nzW/0s2ee+qNzfYFy9itRZA9slecB92HRk+fV4BiI/pNKW 1T0llyDDsfTLEy5pdditK4cV1V6nmcl6H1cnv6Il4t9AiRVP8VxlsbgpzLPfDZIkKgfW 6KjDoYyijG+JnwJH0t7U8bSHtZW29tiWqKcB4Wy3+zFWZhhWZLJl8yuSM8KF+pXF7TTw YwwoPYLnvr4ZVg0xueoBHX+VFSXFiNxS/yaSCW5CG1GNurvNf14L8AJ7RJmW4vj6ixWQ Mr4o0qGyJzwBmT0lYZKH/jZPsks/lWHpjnk7gYRlYFtuffx2M2cgG5V0rpiBAdHEtaLF GpuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778653091; x=1779257891; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TX9DcXAmoIgsu4IRPsBLLucku/osUjEAMFhUMNrAFrU=; b=O/m6Ymi2VV90UskrZwwHohn+Ji2w3T4Yq6ukzCGfKhzLcDafdfMDZKU1wycAsy5RtS hSKJFvKj+9LKzi/Xe0HTdbzFm6vbw74eviufY0isCcF9I2SgEVIFU+jJOtwyt/bGo9Jb XkEiWAINXfmGvRQNN9s/m9FXDNXATQqJ986M0Q/y54t+x0/T4XKq+JaUYu5UIAoqIX3k IwThCW079MBRMTH2w2NYm5ZfJOeAJ26b9coJASr+BPxPCHsDFrgqy/XgAjM1yz67vbHX YB8ZPkYB12UXzjbK+hHgjn6WRD6QGeyuuiZXrkaQs7fqrKubHMMtptiXrtq68vOCmBKV JrfQ== X-Forwarded-Encrypted: i=1; AFNElJ9dt2ZX76LqoVj3+PuLFXm4LxEIUpWtrhzcI6ZftZ2VCXVbQgFSq0FN+Buvru/SIU9FftESjbrAkiJpE2g=@vger.kernel.org X-Gm-Message-State: AOJu0YzgIfFYC5/GysdyY5OWSf54bVhoA+syZSfRfL7e2/WRNjDooPTS 3OlD2/eK1nue9fk7/4h6nMBB7a7Aj9h0qc2mERThPFHAoegfqMCloFH1rgGi4b7eULhNdFEvLS9 39zrwe+pjCpJFK5UyACmHu6GwFw== X-Received: from pgno29.prod.google.com ([2002:a63:7e5d:0:b0:c76:6c2f:89d4]) (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6300:210e:b0:38d:fad1:cf2a with SMTP id adf61e73a8af0-3af7ee42920mr2030816637.13.1778653091052; Tue, 12 May 2026 23:18:11 -0700 (PDT) Date: Wed, 13 May 2026 06:18:09 +0000 In-Reply-To: <20260512154628.a30e8eb1827c80e0529b672e@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260512154628.a30e8eb1827c80e0529b672e@linux-foundation.org> X-Mailer: git-send-email 2.54.0.563.g4f69b47b94-goog Message-ID: <20260513061809.3868837-1-joonwonkang@google.com> Subject: Re: [PATCH v5 4/4] percpu: Fix hint invariant breakage From: Joonwon Kang To: akpm@linux-foundation.org Cc: cl@gentwo.org, dennis@kernel.org, dodam@google.com, joonwonkang@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, tj@kernel.org Content-Type: text/plain; charset="UTF-8" > On Sun, 10 May 2026 07:21:49 +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 mainly fixes this invariant breakage and includes more: > > Thanks. AI review asked a single question: > https://sashiko.dev/#/patchset/20260510072149.1279887-1-joonwonkang@google.com Thanks for sharing it. Let me answer it inline. > > diff --git a/mm/percpu.c b/mm/percpu.c > > index 35e058f56a6fd..359f92d9637db 100644 > > --- a/mm/percpu.c > > +++ b/mm/percpu.c > [ ... ] > > @@ -661,21 +710,41 @@ static void pcpu_block_update(struct pcpu_block_md *block, int start, int end) > > if (block->contig_hint.start && > > (!free.start || > > __ffs(free.start) > __ffs(block->contig_hint.start))) { > [ ... ] > > /* new start has a better alignment so use it */ > > block->contig_hint.start = free.start; > > - if (block->scan_hint.size && > > - free.start < block->scan_hint.start && > > - block->contig_hint.size > block->scan_hint.size) > > - block->scan_hint.size = 0; > > - } else if ((block->scan_hint.size && > > - free.start > block->scan_hint.start) || > > - block->contig_hint.size > block->scan_hint.size) { > > - /* > > - * Knowing new contig size == contig_hint.size, update > > - * the scan_hint if it is farther than or larger than > > - * the current scan_hint. > > - */ > > - block->scan_hint = free; > > + } else { > > + if (block->contig_hint.size > block->scan_hint.size) { > > + if (free.start < block->contig_hint.start) { > > + /* > > + * old scan_hint.size < new contig size > > + * == old contig_hint.size. But, the new > > + * contig is before the old contig_hint > > + * so hold the invariant > > + * scan_hint.start > contig_hint.start > > + * iff scan_hint.size == > > + * contig_hint.size. > > + */ > > + block->scan_hint.size = 0; > Does this code unnecessarily invalidate the existing scan_hint by setting its > size to 0? > Since block->contig_hint.size > block->scan_hint.size in this branch, it > appears the existing scan_hint already satisfies the invariant. > While updating scan_hint to free would violate the invariant because > free.start < contig_hint.start, simply retaining the old scan_hint rather > than actively zeroing it seems to preserve the invariant. > Could we leave the existing scan_hint intact here instead of clearing it to > prevent a regression from losing a valid allocator hint? If the old scan_hint is before the new free region, it makes sense to leave the old scan_hint as-is and I don't see much demerit of it. If the old scan_hint is after the new free region, however, leaving the old scan_hint as-is is more likely to break the contig_hint later and I guess it is still better to scan from 0 in that case. So, let me more diverge in this case. Thanks, Joonwon Kang > > + } else { > > + block->scan_hint = free; > > + } > > + } else if (free.start > block->scan_hint.start) { > > + block->scan_hint = free; > > + } > > }