From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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 DE9612D5A14 for ; Wed, 3 Dec 2025 08:43:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764751384; cv=none; b=rmOJ8aDYMI2VGrnPYRmjDHktzQ+oL/oiuop/3PBZtdqQP8xb3a/GfdGWfxU9fpNivshaILZB0CPR58IbCCcf0wqm6fTYRnL/SyqokTiiko5zImpUpqI7fyFzH5q+oNSAhQ6c9/fPkwCV1SotjZD53kSkia1KK4fLw/J1emCs+cY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764751384; c=relaxed/simple; bh=Ktz51W/YIf76AiGC8xMa2bBxdNdgxyjouz6Fws/n0Ow=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EIf9JvR57DqkV9/SSA71Y64d1JKKbFAoFm4u1pbVTSGkldIdp5jlaEQAN595lw8RMuWDAgQ7wRX6gurrytpUDa7Mz8gwWEFO2mKqbCcVnobTyT6pdy9KoGd8T/1NUz/W8e5dkFcn5ARkRqz5r5O9/njcdXVWkqKW1m88ldj2gTc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=PpwsB8Wt; arc=none smtp.client-ip=209.85.208.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="PpwsB8Wt" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-644f90587e5so9777684a12.0 for ; Wed, 03 Dec 2025 00:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1764751381; x=1765356181; 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=vaMrZfXHba2THBbgdK1Ts2PDSgoQN/m0e8n8zxby2CA=; b=PpwsB8Wt24hy5SFbP3u4pcOacH0VyVefT2n2u9QfIhwdUB0JlwCzcnSw96HQ4R+62P NEgo/UOVjWkOgPlw7yNWzptkiOv+5PDd9YIlIG3XyD9Drk4u2itDNMiWlO/40nIjEGIY xVu2y+IbSjd1Owy/8g2wd5k9CwqciR5NsKNKDJkEKxiidWcE06LkZR1WnH9ym3arjHG7 VhqBJmGhRxD+FGXtp1X1KjdJ1D98FtzgUiuzel+AP0v/yLAHSqz6pbX4qLzmazSfHlVK gkJvnFJdjc58D6suoxdrcJXyHP6CbbJpMgGNiF5LKdSElgd6z2H0fP2GkSJ0SnfjIJdD uNRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764751381; x=1765356181; 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=vaMrZfXHba2THBbgdK1Ts2PDSgoQN/m0e8n8zxby2CA=; b=RwXgXcliMuF3AZWY05ZUQ6m/iuWM/OO5skamqA+xQqJ/nMg0KoH/No5kNJiRt6eSt2 dNIiVJd6V/QgpS2wxPyJWiANmarOR35d3V7N9rKTQicgSICSXgwxfN16Ku372cFfLxAt 7c8qTLpuwCCZlGjZAtkUWezugF3bY8RA7Ph8cmtJSTCTXaisT8DZG59PCAp6Tz1rMoqr Kjm5Wkqrj+fuuqKldjDQnJ3DAL2hYJuyD0DvUfgyYkOt3LFV5PJezAdvpQOj/8KDsDaZ ctueSKIbzeSyYRQatQ3v+W9FtaYb51O30u9nulk3xWG/2EHg3kZzoPs/AO1lCWsH5Tsh n4Jg== X-Forwarded-Encrypted: i=1; AJvYcCVdKxQfbmOOPL1ywcEy9m3szLw9/89HKh491zBVHKr6wq8TSH4IRasgedN7SOHdQn5q7tF0HeEVzwh8g04=@vger.kernel.org X-Gm-Message-State: AOJu0YzZyaqgzi+V8UKmVatmR06dIQWrort01hikuTOmpHQnqwgJ2s6F lOkxFysGHeZZQ6scd2wv+/P/mZiWqvDRbry/LGG6Z8pErYvVX4kqlTrfLYz73UO/AQs= X-Gm-Gg: ASbGnctrW4UGJ/dsGjI3elZj5OfFtfpDIpAHco1ce1XMb45TFm7/WyKnVj6L7SdRxXj 4kcI1vbaxSIK5BxUJJwDTFXJ/h6jOpuy2IpohKRZPivLG5gCuFLl89SZ4HExaNOoJs0iTv1RxUP g8KJGDbFU/KSgdKox7wzhYnqHGQjYlye7/A1lzPPKt7/oOewe5hSaWHkxvcVcDaVPJKCUDoqI6U UW15ppOWspccqcvnCf3fRQYbQCp2BR3pCmysewgUhZ3TM1VP5eVOI0fxU/RrYkhmKJQHUJY9Lnm w9i1rsf41M7ZBeGH5ykqL9yaAzMdKHtkZIQQddMUuY9eoFUIif9A1WKmefFwaG0MQvk8Gt20e+q k1kHWoFhAsoufQ96feNlTHX2YjGlMMWnM1y4JRB31N6qZDBUtVp2EdMDkeCd0uVYUP7gtvLmhsq EmRhTsSsXlbUnfAd3Wp32tmEye X-Google-Smtp-Source: AGHT+IH+dftZi9M4w7GOU5TZKpaqX6jfLAYFXQrFmgXkYHpbvFapvbAcqhxOMo99WFjg1NtntfJDiA== X-Received: by 2002:a17:907:d02:b0:b73:2d99:d8a3 with SMTP id a640c23a62f3a-b79dc4ecb4emr134909766b.26.1764751381046; Wed, 03 Dec 2025 00:43:01 -0800 (PST) Received: from localhost (109-81-89-155.rct.o2.cz. [109.81.89.155]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b76f519e2f0sm1758679866b.21.2025.12.03.00.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Dec 2025 00:43:00 -0800 (PST) Date: Wed, 3 Dec 2025 09:42:59 +0100 From: Michal Hocko To: 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 , David Hildenbrand Subject: Re: [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free Message-ID: References: <20251201060009.1420792-1-aboorvad@linux.ibm.com> <20251201094112.07eb1e588b6da2ee70c4641d@linux-foundation.org> 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: 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. > > ~Gregory -- Michal Hocko SUSE Labs