From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 0491037C108 for ; Tue, 24 Feb 2026 11:27:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771932432; cv=none; b=T1nPsbnRc7grJjjCxF5X6s9ecE7n4a5PodoBTpq7ahApXBiF1vtcnhpscdb5Uwf6lj2T6fvhebb9oRdKiCjVNRN4dPzln/fuUdq4CRJW92gl8BVSFbD5Hz+hAUnbrXCZay1RBTbJXJqzICBmLiBG/norz85Ev/GzPe0K6i9QM6I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771932432; c=relaxed/simple; bh=ng+Nx/b9d4V+N+mQqs1YRMrAFYLDaza0plzDmLxFyOo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Nig/dzbzCNbZ/FMyxgrFz2NetPv/IDe9OvRiiZO3ep+znA+UvlICbJ4aWLNfrqXaYHvzvoqSzqicwoleTdT4Qejq5AY9IU+YkS7l1vXoWGNuDzMYmNEODM5IQlZCSgfloZmUWnRBkLat8RLaEn9oD9/KrzfpHUfTXHENpf7f1Zg= 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=aquLdW0A; arc=none smtp.client-ip=209.85.221.54 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="aquLdW0A" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-4398c7083d7so76640f8f.3 for ; Tue, 24 Feb 2026 03:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771932429; x=1772537229; 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=e4wckwVW0b3X1g/PGVWHQbxmb/kww/W4UTrCJT/v/yM=; b=aquLdW0ABgx1qBmyGtZ8RNmdOCrqEtvKdmJpPtWhb1n4uGm6XfRU6gf3Bt95Tnopr5 QNVvfA8kyC8F/+szeJF2ovRtz4F9NGzB5UfwUHcykUA4WD29k7WfPuNmf/no7QEUWnND NRyhm5tYIh2KaT6cYehjbtoBNpgZoJ9tUPCjrrz/hwcm5ITx9SngdQJ4gGzZGQ/ehUQn 6lcYtoiJOQwuH0/JcdPd4Fhxb/pHfFvdgtOdGBDgQaFVMhLBocHUBOTD0y+osecuI+TE PiqLZ9sYe3P4AsGydkheXoLd8Eez0GbPd6e3coeztfGPWV3Ge7sJQqBq1GXrgcylney7 tmdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771932429; x=1772537229; 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=e4wckwVW0b3X1g/PGVWHQbxmb/kww/W4UTrCJT/v/yM=; b=dfZ1r96ef0TGW7MZ7lngJ8GJ0VcxWgi04TlP88qiqyuoa45Cf/jqJmtmCOD4Iiv+/n gc0Fh8rgpggiySqo5VPMcCOQKUoRs1Q5pntCy2gm4F5H4924KqtseVHIcnJLIQxxUvAU n4K0mb4zvkUYPJ9owZQOZP7qjgnEY3kDznugssSyMt/YGbLQZiIKNdtKSdnX6UAw41go zSk+CcSlKHl0NTSrv4jubJaWr1ex3goAOu3z9IX/7Et959NEQT6M4FqP6CYJea0wCxi5 69IHVu6+F/k/q+pROFEMtnKnjXZDrCqGXOJG5CGpYdeuwu8QRUqixm2BxnLFU8L0hCP6 ZtGw== X-Forwarded-Encrypted: i=1; AJvYcCXxQN/OWK5TxoG4DhErzExB4fXwvegj11A5spjyIFVuZDz1tLy2w/o5xVeSjuumBaom57h3Kt7J8iO6soI=@vger.kernel.org X-Gm-Message-State: AOJu0YyA2ukoQu1uiu9DEAKjZ7Cu1Uc4Lf8H2aAKGt6Xt3UwecL3uKu0 VLzjHaGCumf3DXU6ZNXpPfKGY2rXssg7PyOefyw3iLqG9J4Kp6ZU9qJyUbY3Nsy6lXc= X-Gm-Gg: ATEYQzz9oOPWXniMLzKEkfzJF5DZxtqtIYzj1VFYMO2DCvpNdljDIV+JrynAoKP84k2 xRojx9HsBgxJL2UpiRL83G6ew3a55Vl/dt8FGzVqO2QBFH9mZPFDlwiJsiGMl9reNRLg7whEfhm 7CSNSfYrt54V72idNFVdF/IgavfCgLqkrp9fFhouKbCL7Fq4ZWElve4ADiTFmReagFsEDLhZz+U P4qMNIe7t2Q5+lz/o6uAy3cTOIgMxntRye++GRs8m1WSmGDjDBBBPw3TIPQ8Y8IRbSejRidDlUW mp+GWfXgYJZ3na/u+F6Rnl2fjoUR80NeHpnvicbMb/HPdv/inlC44uYsJCXDHmK5iSG60f5u59H Ppqpy1O4csn67AlmiD8NkBGzo/azqK47iq1f68iqkrIsWneHbcKVaTXI7zQuc1/fSI7LF0dkKzp TaFhW8+RjjYUeCiGlRV8izpMNLFWdXWIk= X-Received: by 2002:a05:6000:26cb:b0:439:872f:b496 with SMTP id ffacd0b85a97d-439872fb5b4mr2656294f8f.59.1771932429230; Tue, 24 Feb 2026 03:27:09 -0800 (PST) Received: from localhost (109-81-84-7.rct.o2.cz. [109.81.84.7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43970d4c977sm27358404f8f.32.2026.02.24.03.27.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 03:27:08 -0800 (PST) Date: Tue, 24 Feb 2026 12:27:07 +0100 From: Michal Hocko To: Joshua Hahn Cc: Gregory Price , Johannes Weiner , Kaiyang Zhao , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Roman Gushchin , Shakeel Butt , Muchun Song , Waiman Long , Chen Ridong , Tejun Heo , Michal Koutny , Axel Rasmussen , Yuanchu Xie , Wei Xu , Qi Zheng , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [RFC PATCH 0/6] mm/memcontrol: Make memcg limits tier-aware Message-ID: References: <20260223223830.586018-1-joshua.hahnjy@gmail.com> 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: <20260223223830.586018-1-joshua.hahnjy@gmail.com> On Mon 23-02-26 14:38:23, Joshua Hahn wrote: > Memory cgroups provide an interface that allow multiple workloads on a > host to co-exist, and establish both weak and strong memory isolation > guarantees. For large servers and small embedded systems alike, memcgs > provide an effective way to provide a baseline quality of service for > protected workloads. > > This works, because for the most part, all memory is equal (except for > zram / zswap). Restricting a cgroup's memory footprint restricts how > much it can hurt other workloads competing for memory. Likewise, setting > memory.low or memory.min limits can provide weak and strong guarantees > to the performance of a cgroup. > > However, on systems with tiered memory (e.g. CXL / compressed memory), > the quality of service guarantees that memcg limits enforced become less > effective, as memcg has no awareness of the physical location of its > charged memory. In other words, a workload that is well-behaved within > its memcg limits may still be hurting the performance of other > well-behaving workloads on the system by hogging more than its > "fair share" of toptier memory. This assumes that the active workingset size of all workloads doesn't fit into the top tier right? Otherwise promotions would make sure to that we have the most active memory in the top tier. Is this typical in real life configurations? Or do you intend to limit memory consumption on particular tier even without an external pressure? > Introduce tier-aware memcg limits, which scale memory.low/high to > reflect the ratio of toptier:total memory the cgroup has access. > > Take the following scenario as an example: > On a host with 3:1 toptier:lowtier, say 150G toptier, and 50Glowtier, > setting a cgroup's limits to: > memory.min: 15G > memory.low: 20G > memory.high: 40G > memory.max: 50G > > Will be enforced at the toptier as: > memory.min: 15G > memory.toptier_low: 15G (20 * 150/200) > memory.toptier_high: 30G (40 * 150/200) > memory.max: 50G Let's spend some more time with the interface first. You seem to be focusing only on the top tier with this interface, right? Is this really the right way to go long term? What makes you believe that we do not really hit the same issue with other tiers as well? Also do we want/need to duplicate all the limits for each/top tier? What is the reasoning for the switch to be runtime sysctl rather than boot-time or cgroup mount option? I will likely have more questions but these are immediate ones after reading the cover. Please note I haven't really looked at the implementation yet. I really want to understand usecases and interface first. -- Michal Hocko SUSE Labs