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 C5618158535 for ; Wed, 3 Dec 2025 08:51:58 +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=1764751918; cv=none; b=ZyNeJqNZQFV6mQk3Owl7dM0KeifJ9cTEaa//1Qvhu9qPIB+KjTmtN/yLVBh8Z+O/SPZv9u5zqkMlwlvqhlWQJepAC50+fIsWpOcvlkhJhqVORFYyszCLH3xHsxJlGcSMtLo4ogMJDz4HYwzrqJc/LO6GwpzzhoQGEzckFQuEjfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764751918; c=relaxed/simple; bh=+ZBqsXW0idRjNcytHlxgeXbrst/E2IBgJlHKuXQWrC0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=E6u6o/kfXuPFuNra+7ft3iWBhm0KjhHBUbQi98xhGUFFSoEOOEft1lk+4+shNCCMAVdX3qeKx+oZBqgepiCwuPHatBLLMRbWXtuUadnPl5Z7gfuKXoW93OQvgaugRWhr+zKkS8yeQaYSdTPI5DldpM1uR5oiZMa6/Nsvjsc8J8w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hF3Cy6le; 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="hF3Cy6le" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 744B5C113D0; Wed, 3 Dec 2025 08:51:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764751918; bh=+ZBqsXW0idRjNcytHlxgeXbrst/E2IBgJlHKuXQWrC0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hF3Cy6leWJx9PRGbugpsiWwVDB8ZaWghKgw4dnWBAVQp8UEVz3djuUxrOyVc8kqzU IymAdPyLJsJvwEMpjs6O3osmuJU+IstFRP63GhDemZTSW1LbRKuTClWFpUy5Tb3LDn 4c3plGohnB3lA6/hLVlBdfPyFUZPv1kyesd2FqYOpjxZs2mT7Ysgj9hlo++KYyBJr7 E0hLgkGB8JwMN/sDZblxXTv/Sqzp9i8fc0hNi5PT0AvKoTDEc0df9QZk1LvqvMjAMw JE9rTLbnH687m4bsow1CWNLeSlSYslIx9cruIxsI/4AQ7wRRyrrqIGjb+DKA3g21G5 8myi/sfbG+l3g== Message-ID: <47a8b4d5-f4d2-4772-b1b2-ee96bc21e742@kernel.org> Date: Wed, 3 Dec 2025 09:51:52 +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: Michal Hocko , Gregory Price Cc: 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 References: <20251201060009.1420792-1-aboorvad@linux.ibm.com> <20251201094112.07eb1e588b6da2ee70c4641d@linux-foundation.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 09:42, Michal Hocko wrote: > On Wed 03-12-25 03:35:51, Gregory Price wrote: >> On Wed, Dec 03, 2025 at 09:27:26AM +0100, Michal Hocko wrote: >>> Let me add Oscar and David. >>> >>> On Mon 01-12-25 09:41:12, Andrew Morton wrote: >>>> On Mon, 1 Dec 2025 11:30:09 +0530 Aboorva Devarajan wrote: >>>> >>>>> When page isolation loops indefinitely during memory offline, reading >>>>> /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock, >>>>> causing hung task warnings. >>>> >>>> That's pretty bad behavior. >>>> >>>> I wonder if there are other problems which can be caused by this >>>> lengthy hold time. >>> >>> pcp_batch_high_lock is not taken in any performance critical path. It is >>> true that memory offlining can take long when memory is not free but I >>> am not sure we can do much better. I guess we could check contention on >>> the lock and drop it to make cpu hotplug events and >>> sysctl_min_unmapped_ratio_sysctl_handler smoother. The question is >>> whether this is a practical problem hit in real life. >>> >> >> I just today hit a scenario where offlining was blocked on migration >> failures that took an exceedingly long time to offline (many minutes) >> even on a relatively small block (256MB). >> >> Now that I'm looking at the double-do-while loop in memory_hotplug.c >> >> zone_pcp_disable(zone); /* (pcp_batch_high_lock) */ >> ... >> do { >> do { >> ... >> cond_resched(); >> ret = scan_movable_pages(pfn, end_pfn, &pfn); >> if (!ret) { >> /* >> * TODO: fatal migration failures should bail >> * out >> */ >> do_migrate_range(pfn, end_pfn); >> } >> } while (!ret); >> } while (ret); >> ... >> zone_pcp_enable(zone); /* (pcp_batch_high_lock) */ >> >> >> 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. -- Cheers David