All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Tejun Heo <tj@kernel.org>
Cc: intel-xe@lists.freedesktop.org,
	"Natalie Vock" <natalie.vock@gmx.de>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	cgroups@vger.kernel.org, "Huang Rui" <ray.huang@amd.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Simona Vetter" <simona@ffwll.ch>,
	"David Airlie" <airlied@gmail.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Thadeu Lima de Souza Cascardo" <cascardo@igalia.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/6] cgroup/dmem: Add reclaim callback for lowering max below current usage
Date: Tue, 07 Jul 2026 09:20:35 +0200	[thread overview]
Message-ID: <67ffc76ee6d1aa4e9ef5f4c393304914359eeaab.camel@linux.intel.com> (raw)
In-Reply-To: <akwBFlw8MwhrwsRu@slm.duckdns.org>

Hi,

On Mon, 2026-07-06 at 09:25 -1000, Tejun Heo wrote:
> Hello,
> 
> On Fri, Jul 03, 2026 at 03:05:38PM +0200, Thomas Hellström wrote:
> > Also honor O_NONBLOCK so that if that flag is set during the
> > max value write, no reclaim is initiated. The idea is to avoid
> > charging the reclaim cost to the writer of the max value.
> 
> Is this really necessary? I'm not necessarily against it but this is
> trivial
> to work around from userspace and feels like a gratuitous addition.
> What's
> the use case?

This was something that was added at the request of Maarten. The idea
is to mimic the memcg behaviour. For memcg, the use-case was to avoid
having the reclaim cost (I assume in terms of cpu time) land on the
next allocator instead of the process writing the new max value.

I think there are more details in the memcg commit history, but the
presence here is solely to mimic memcg WRT this.

Thanks,
Thomas 

> 
> Thanks.

  reply	other threads:[~2026-07-07  7:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 13:05 [PATCH v7 0/6] Add reclaim to the dmem cgroup controller Thomas Hellström
2026-07-03 13:05 ` [PATCH v7 1/6] drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() Thomas Hellström
2026-07-03 13:08   ` Christian König
2026-07-03 13:11     ` Thomas Hellström
2026-07-03 13:26   ` sashiko-bot
2026-07-03 13:05 ` [PATCH v7 2/6] cgroup/dmem: Introduce struct dmem_cgroup_init for region initialization Thomas Hellström
2026-07-03 13:05 ` [PATCH v7 3/6] cgroup/dmem: Add reclaim callback for lowering max below current usage Thomas Hellström
2026-07-03 13:24   ` sashiko-bot
2026-07-06 19:25   ` Tejun Heo
2026-07-07  7:20     ` Thomas Hellström [this message]
2026-07-03 13:05 ` [PATCH v7 4/6] drm/ttm: Hook up a cgroup-aware reclaim callback for the dmem controller Thomas Hellström
2026-07-03 13:19   ` sashiko-bot
2026-07-03 13:05 ` [PATCH v7 5/6] drm/xe: Wire up dmem cgroup reclaim for VRAM manager Thomas Hellström
2026-07-03 13:05 ` [PATCH v7 6/6] drm/amdgpu: " Thomas Hellström
2026-07-03 13:25   ` sashiko-bot
2026-07-03 13:27 ` ✗ CI.checkpatch: warning for Add reclaim to the dmem cgroup controller (rev7) Patchwork
2026-07-03 13:28 ` ✓ CI.KUnit: success " Patchwork
2026-07-03 14:11 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-03 14:37 ` [PATCH v7 0/6] Add reclaim to the dmem cgroup controller Thadeu Lima de Souza Cascardo
2026-07-04  0:07 ` ✗ Xe.CI.FULL: failure for Add reclaim to the dmem cgroup controller (rev7) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67ffc76ee6d1aa4e9ef5f4c393304914359eeaab.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=cascardo@igalia.com \
    --cc=cgroups@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hannes@cmpxchg.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mkoutny@suse.com \
    --cc=mripard@kernel.org \
    --cc=natalie.vock@gmx.de \
    --cc=ray.huang@amd.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=tj@kernel.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.