From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 DCAB13AFB18 for ; Thu, 9 Jul 2026 06:11:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783577486; cv=none; b=Z5rlZyVE5m/2ju4BynpQ/RD71OWa/SfkpQiQV8cvLE1ZRsnc0WUClosKyZIYDZVnnUVFpAlJOXuVIqX2QsJC7HFwkkZii2hXoFb9h4faO++gLrXZcz5GpKVTv4DZRmJ0HoHjPGg8ban+O/gzzm9nPAt7VyFkCiEgo4faYP0+V4s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783577486; c=relaxed/simple; bh=EUgxUMI4K7JFDpVXkNKVUQFFCv3LFfWMvknmwoGt5yo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IJhJb4zshzkH7awZbZ+1pnEDqpoDuRNgBloVflPXUoyQyl1UBSHe9f9JAUyALAV4cmyj+8xogSIGDsGn3QrRnnh+hzKhw22hY9LgIclh6QkVgck8Huz5cOkz6y4MVjinmXUts15uAHEMBHFeS7xHRdocTHVXz7vgIeIM+xyGX/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rKxOtsYv; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rKxOtsYv" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2cc61541f8cso8326825ad.0 for ; Wed, 08 Jul 2026 23:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783577484; x=1784182284; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Hd6GoWd0nNSvkzn4bZsOD9QjS5q1cvBf4vz24CQIaxI=; b=rKxOtsYv1lWdrEy4qahWaetYQlPfcjAwdcMrO6qs0htyGPA050gFAozjx/uOqokN4U h0XsY9vZ2CzBuMf3LAKxsTKK/ncyrKLceQjVDZ90mxWVn+o/PugBnxtP8KTGr095O4Xt 8Z4rmxaJOj/ETGqMU0Fgxj7No9WaaOdyzkzjvxK6xbsYUXF30foMT4wLJPM84E2SWApJ 6edOmneTAWrE8i0s8O29x3J+ouK5hWwwDNztBCP7kRBKDQLUzWuXafLAVKBtIW9s1KSi Z/mIGQozLUM2LbioRdN8Y2FMXw5pdX0+SV52IxGN77J3jO3lz9dh2CVzx6AXDSVRdl5s o0lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783577484; x=1784182284; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Hd6GoWd0nNSvkzn4bZsOD9QjS5q1cvBf4vz24CQIaxI=; b=D3+QmkHQHvt1GZwKDqK9GdI/9ik7+Zs3pRdvxqjhkXZSFvCVQQZiTDAd4q8egPFQZj P/J+3vOyL3CVCLgLA7wVddsyRh7+ddMAFhWCfhphRl7N02y4kJo1J3OgdZ/s6MCkI1H6 1H6DtPZKs6SbLM2rEfC2hVZ7Tyr1kURK0nmmvSyOQtbVzQOY6YD+ZYwFa4B3pxzEpAAr mO60IuPxzqWwa7qF3UQeYsHuehjMfkYcBVMIQFNd7QER4o1It3EMlGVcLJQ5MT1l73Gh rb0zmLpEXgV9/TshGx+IGgnE7Do5J5tG7Y/TXKjT10LY4K+eBstSYv5O46E/osrDugJR Djzw== X-Forwarded-Encrypted: i=1; AHgh+RqIEgGKITCazuHy0yv3bi+2qb7B1vXbSDbEfUAKraBInRUTB23qm5tptBOr7xPT0r5h9lLbinmyh64pfQo=@vger.kernel.org X-Gm-Message-State: AOJu0YxHMpcfqJYstuI+w+e2ODdrZDuBLh4W0np69GsMzJhD2vW8onOM cDypFFJ4sXIVWQSVj1TUmkf094a24YHNKClMYhBqB2t082n0JRw/IUlI X-Gm-Gg: AfdE7ck4kZJkc89vluiogj1FVZFXRJOgH60tci8z3i/1i+/epT7O0C8+CMm19n+cQDL /1vCePLW3QApt/niWPfiMx5ksZWqEEcGObamtb/iy0a505SnlXZPWcNQYVW4nzc2fMCqD6YJWau rQysNEb5VVHWqLMCt3Uhjleia0PxxeyoQ0gTRZT26stIk7UvYj1YPSOnyrKsquUA8enGyCe4q0O e5hStRTrz3LJ2g4vWPySAeTzk61jb8zg42Bxa7JtLcKKRMCEP3uCuxbJVjyfyexFwFxHN3tkQUf Ds+BqWtv6WyE7RJi4Jq+GDjd2FgSLKigDIvyFP8mKQBVi31eiHccRGS1VEwWsxCerNqEnjwhq8c n8/53T0dIHZyDVjD2C4GggYWHLN239+psaVTi+3FoYDWGzg6ldmSQsUzf3G6ePrbPnmI8L+m7gl et+ImcjRw= X-Received: by 2002:a17:902:ce0d:b0:2c9:d27b:af11 with SMTP id d9443c01a7336-2cdd8a84479mr14704525ad.11.1783577484149; Wed, 08 Jul 2026 23:11:24 -0700 (PDT) Received: from ubuntu.. ([138.199.21.246]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccc9d602fdsm37778845ad.81.2026.07.08.23.11.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 23:11:23 -0700 (PDT) From: Jing Wu To: matthew.brost@intel.com Cc: thomas.hellstrom@linux.intel.com, christian.koenig@amd.com, ray.huang@amd.com, matthew.auld@intel.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com, natalie.vock@gmx.de, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Jing Wu Subject: Re: [PATCH v7] cgroup/dmem: implement dmem.high soft limit with proactive reclaim Date: Thu, 9 Jul 2026 14:11:13 +0800 Message-ID: <20260709061114.1623774-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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=UTF-8 Content-Transfer-Encoding: 8bit On Wed, Jul 09, 2026 at 12:44:37AM -0700, Matthew Brost wrote: > This looks quite similar to work Thomas is doing here [1]. Thank you for the pointer, Matt. We were not aware of Thomas's series before your mail. After reviewing Thomas's v7 [1], the two series turn out to address different — and complementary — problems: - Thomas's series hooks a reclaim callback into the dmem.max write path: when an administrator lowers dmem.max below current usage, the kernel calls the driver's reclaim callback to bring device memory usage down to the new limit. This is analogous to what happens in memcg when memory.max is written below current usage. - Our series adds dmem.high as a soft limit enforced in the charge path: when a successful allocation pushes a cgroup's usage above dmem.high, TTM proactively evicts one BO from that cgroup before returning. This mirrors memory.high semantics in memcg, where reclaim is triggered per-allocation to keep usage below the soft threshold. Both mechanisms coexist independently in memcg and serve distinct purposes: the max write path handles capacity reconfiguration by operators, while the high-limit path provides automatic backpressure for workloads approaching their quota. Having both in the dmem cgroup controller seems correct. > Are either of you two aware of this seemly overlapping work? We were not, until your mail. Now that we are, we would like to coordinate with Thomas on a few interaction points: 1. API intersection: Thomas's v5+ replaces the bare u64 size argument in dmem_cgroup_register_region() with struct dmem_cgroup_init (which bundles the region size, reclaim ops, and driver private data). If Thomas's series lands first, we will adapt our patches to the new registration interface. 2. File-level conflicts: both series modify ttm_resource.c and ttm_bo.c. The changes are semantically independent and should compose cleanly after a rebase, whichever lands second. Thomas, would you be open to coordinating on merge ordering? We are happy to rebase our dmem.high series on top of yours once it lands, or to split out any shared infrastructure as a common prerequisite if that helps. Thanks, Jing Wu