From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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 3DB6432936E for ; Tue, 6 Jan 2026 16:59:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767718765; cv=none; b=u99Yft/c+hi7CpagqE7ITCaEu83drNM/ifFs0qK9TnTbx6tn8mM4UK1mt301fJRroZaiWANETjplXqH01CdLeT0jexSfw0rpr+fL4PBIVl1/wyhBoFnGbNrIZ6eVxwaK0o3WdOwh0kDzVRVvfUoJ007WnpKcBE5+z810rIKIo9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767718765; c=relaxed/simple; bh=24vpcDy9uGOEvFR9gENDnMUkKuDYkr8Rog7AgmGhlcU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y7Uqdi7jqep2LOFr3cprRxrO7DwiYJe/GMMezJqGR7ZWm4xnp6kgpbM+bGwzcxeZQCRbEvI6xPm/e+uujleu9CCIpk2OI/+TTBpDsTTs+PvvPlcJbpdgtuDkdPBWZEth2v/Y4GYz0GPPPu0icV7pUfCpy//Mt2eVLPwQ4PrCT7E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=ldKWAF0n; arc=none smtp.client-ip=209.85.222.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="ldKWAF0n" Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-8bb6a27d390so78464185a.3 for ; Tue, 06 Jan 2026 08:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1767718763; x=1768323563; 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=O3BneFL65T+Jb3L2foMcJ0M1ozwC7vPPWeZ3rcayR0c=; b=ldKWAF0ny9m+9HzucS8jPtDspBrFBTWs5eVBYdpTWJ8GC2oGl6I8EsdYaakyq33ORt N8V9Xo499iG2Xn/tggUD3zRCLnyzRFS4Oic8wS+3F3nwxAd0wVXAxgF32dB+ahoIuuho YMII5hDOvLWXtQQrVC/940lwMeQdqsEtJcfNC5XKwzFoPeMxW8ylJal99g3w5YRwY+5Z cGyVV77Xnf1bnx38zJjzVWt06eC/QClZiR7cSIAb3GUqE5W6HMLcvwjlOuWCqlaoLq9D nD9bvPmsLiSb/qWS2EsiN4DIDbv6JmcZkUAIwGDge8PoLmA/PqxDa4Wp7QU35mTDcsD3 cBvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767718763; x=1768323563; 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=O3BneFL65T+Jb3L2foMcJ0M1ozwC7vPPWeZ3rcayR0c=; b=DoJmLSoM1lFw4A/PkEfER32m7B5MuxY4FBmGfxGiYAMYiEVtxBBLz0LYIbYIoy73eF NldrFwzB+nGzHqiJQUr2CGnwXtHdNJyD4Tbms0BLQdBZzthecv/y7aY6AYeBlfFzB5bX iw1pCjJvE7FE+piXbUT9bdx0h60zWe21CgceqD4N5tol2BsBWpup6tUUOh3lXkoVr6ew 2Xe8/PEtLuE2AQmy5Nb5QJqJLsftQ4p9SwoCvbr5xqzHgBnpXFLeAuwigPXnoqB8Kef8 cKLUAFCzWZJ0oih71TrnydCHBgmALM17UPDYI5jxpC+xGpA1BTOO0tFB+/Oxco9AuLk6 UGOw== X-Forwarded-Encrypted: i=1; AJvYcCUrKi/KUybkAn38tHl7qRC1bfHmJ5T81jbIB3CH7fjoLUwtFcCqGj8pYU5QGUxFFSskvvsxk6cLOjw9rPE=@vger.kernel.org X-Gm-Message-State: AOJu0YwAs5ZhxbDMEwB0Pn3VvFqZ6iiQOQYq3smksidvl1s/9I+Yw+D+ hp0YKLjTGxK74zuKaeZcDFOjdGe8cCqBPoHd+bc5Mwz8cxhcAqvyGjUW/bSKm9iWGok= X-Gm-Gg: AY/fxX7RzbezGb1AI87k5vh4+JbAgVqB/zFX2FDXkkcku/fuzRtuBgb2xmdfAP6U4GW uLOjiH9TCPobWwHWWTTfzp6+M6SvLHnaaBJoFic9l2JLCMyYt7BMaTxoBPJpQHwY0/DdC9Jscus cb4+UTYHyEl1o23cgutG3XhyHCafBI8TPSqeT5TvElY9x/gi4yc5tTM6p9Nk7tQiQ3DHRU4rGmX j0Ghr7tJ/4hHsrhT7dhbWsdrNsZb01oR5DXfdronVdfEOaW0wSiM7rYMnc0qqHRf1WuM6Y6TbQD wv22P9wAIA/hXH6w4m+z3PFe0pPbZHlbWP2P56Hic/KtGmrDDsV5oMbOpDDtYcjdRBGzXBtOY94 S2Hnj56UGGcIGCpdpS1iP1ZiAqjdi6F5L4ObWjVp2W2/W1mhbWONQqYRxuDXUtMdVxCulgVr9go nxMwPv7s4QOU04J7nfLNSzNwhmNQ/Gw7AsxwBRWLavGBO8BKjk485h04EVs0lcDzPdcWun8g== X-Google-Smtp-Source: AGHT+IGKsdLqZ2LvyByKJrbieH6Nc7PzW+X+bQE1oCIF6GKo00ybcMZfJ90IlNxmLw5vXuW4tpCe0g== X-Received: by 2002:a05:620a:2893:b0:8be:dd2c:a0fd with SMTP id af79cd13be357-8c37ebc18a4mr465735385a.44.1767718762826; Tue, 06 Jan 2026 08:59:22 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c37f4a7962sm195418485a.11.2026.01.06.08.59.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 08:59:22 -0800 (PST) Date: Tue, 6 Jan 2026 11:58:48 -0500 From: Gregory Price To: "David Hildenbrand (Red Hat)" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, osalvador@suse.de, gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, hare@suse.de Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory blocks to zone movable Message-ID: References: <20260105203611.4079743-1-gourry@gourry.net> <7f053290-6b9a-4d18-936e-0f28006c79c3@kernel.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: <7f053290-6b9a-4d18-936e-0f28006c79c3@kernel.org> On Tue, Jan 06, 2026 at 04:24:21PM +0100, David Hildenbrand (Red Hat) wrote: > > +/* > > + * Restrict hotplugged memory blocks to ZONE_MOVABLE only. > > + * > > + * During offlining of hotplugged memory which was originally onlined > > + * as ZONE_MOVABLE, userland services may detect blocks going offline > > + * and automatically re-online them into ZONE_NORMAL or lower. When > > + * this happens it may become permanently incapable of being removed. > > If it's really only that, we could also look into simply making a re-online > without a specific mode ("online") to use the previous mode. > > We could glue that to the "contig-zones" policy only, to not affect > "auto-movable". > > That is, remember the zone to which it was previously onlined, and then > simply re-online to that one. > I know we do this in memory_hotplug.c to rollback to prior state. I did notice in... i think it was either memory.c or hotplug.c... that we end up setting mem->online_type=MMOP_OFFLINE after comping an online operation. That seemed confusing and maybe we can use that to store the current state. I'm not against this idea, but it also makes the sysfs a little more confusing (`echo online` now does different things based on prior state). I preferred just failing if the block wasn't compatible with the zone (maybe making it more clear with a dmesg print?) Anyway, let me know what your preference is, happy to pivot however. Hopefully Hannes can add additional feedback and guidance here. ~Gregory