From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 8392E2D592A for ; Wed, 3 Dec 2025 09:09:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764752943; cv=none; b=A/RxZfZGS2rEDU49MHHLQUb/W7m7jdUQCZp3QZxpdCK9ZJ94aprFW+GJOvYmY59uftBvvCCzV+1HMVLxEwd59uKaOhlcFnq59pBz5ZxWj24Lnmma5dN7K8IRktp7Zoyb3cpB2klJK/8ecLiC1+KxZsSSUhfnuo4+9PcQadYszU4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764752943; c=relaxed/simple; bh=DGboUdc02G+DpViZWqGDqlr+OdnJvgeqDqzt2njLLJw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nky8We8Eu9Nl8O4SNRXTPb2mLv2p7dS2BRkhgj+wy97cYQNCFUIw4PB/29ZSBFRyLzN7Nihq2uH0kljzYEZR8AEgw38GZRUOfK5JGL0hXxuFLtP/wvIt8DQMcen1/OsFJXn5m6o1JjLtzf/SGXdBqhge2P4TbMV3fh0AJJETNmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mz1okwY4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mz1okwY4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A5E5C4CEFB; Wed, 3 Dec 2025 09:08:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764752942; bh=DGboUdc02G+DpViZWqGDqlr+OdnJvgeqDqzt2njLLJw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mz1okwY43bzv4DlTzIIKufOUolxcKo3ZlDf9oXnl1kBfxRtkyXPKPPB8dmRVvkLpf +Lm59YXef5cp3XRt5HQ4vjYd89/HqujIOYEW49KRIpAthAMQTFAKjHsvBWun107H2N CqrYLOn74KV2z6hkqT6S2Lz0mYXwnhWjCSKjDla0/V0TNhSQYzXvpGzRBDekyeKYfx 3FMgFXtSK92YfW6brdHJGMPsffQr/elM8Zjk3iN6MqNDrp2QlZylNNUyC51eVKIlk1 E2USKfQeaNffNCSlkMIl7LWnFQEZCqMXbICtx5pDR51CwlAkTIIK6fD8Wp9DF/zVCy TtKn60RSOuYmQ== Message-ID: <9de2f7e2-a202-499d-8858-6936beb251d9@kernel.org> Date: Wed, 3 Dec 2025 10:08:55 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free To: Gregory Price Cc: Michal Hocko , Andrew Morton , Aboorva Devarajan , vbabka@suse.cz, surenb@google.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador , Juan Yescas References: <20251201060009.1420792-1-aboorvad@linux.ibm.com> <20251201094112.07eb1e588b6da2ee70c4641d@linux-foundation.org> <47a8b4d5-f4d2-4772-b1b2-ee96bc21e742@kernel.org> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/3/25 10:02, Gregory Price wrote: > On Wed, Dec 03, 2025 at 09:51:52AM +0100, David Hildenbrand (Red Hat) wrote: >> On 12/3/25 09:42, Michal Hocko wrote: >>>> if (!ret) { >>>> /* >>>> * TODO: fatal migration failures should bail >>>> * out >>>> */ >>>> do_migrate_range(pfn, end_pfn); >>>> } >>>> ... >>>> >>>> Maybe it's time to implement the bail out? >>> >>> That would be great but can we tell transient from permanent migration >>> failures? Maybe long term pins could be treated as permanent failure. >> >> Did we try offline a ZONE_MOVABLE block or a ZONE_NORMAL block? In case of >> ZONE_MOABLE, bailing out is not really the right thing to do. >> > > My transient failure (although i'm not sure it was actually transient, i > killed it and retried after a few minutes and it succeeded immediately) > was on a ZONE_MOVABLE block. Okay, so that one should not bail out. Longterm pinnins must never end up on such memory, and if it happens, we have to identify why and fix it. We have this known problem of "stream of short-term pinnings" that can temporarily turn memory effectively unmovable. Juan will talk about that at LPC [1]. We have another set of problematic cases (vmsplice(), fuse) but I would assume that these are not the cases you are hitting. So not sure what exact problem you were hitting. [1] https://lpc.events/event/19/contributions/2144/ > > Kind of suggested to me there was some bad condition the resolved once I > took a second to release the lock and try again. Hard to tell I'm afraid. Do you still have the dump_folio() calls we print when migration fails? -- Cheers David