All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Dave Airlie <airlied@gmail.com>
Cc: "Christian König" <christian.koenig@amd.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	kasong@tencent.com, nphamcs@gmail.com
Subject: Re: list_lru operation for new child memcg?
Date: Thu, 29 May 2025 09:20:50 +1000	[thread overview]
Message-ID: <aDeaUkvbakteBtZQ@dread.disaster.area> (raw)
In-Reply-To: <CAPM=9txMcS4TsU5M8v6yGH7T7vbAFJM_yw0CVdZWPUpWfNLqmg@mail.gmail.com>

On Thu, May 29, 2025 at 07:53:55AM +1000, Dave Airlie wrote:
> On Wed, 28 May 2025 at 17:20, Christian König <christian.koenig@amd.com> wrote:
> >
> > Hi guys,
> >
> > On 5/27/25 01:49, Dave Chinner wrote:
> > > I disagree - specifically ordered memcg traversal is not something
> > > that the list_lru implementation is currently doing, nor should it
> > > be doing.
> >
> > I realized over night that I didn't fully explored a way of getting both advantages. And we actually don't need list_lru for that.
> >
> > So here is a side question:
> >
> > Is it possible to just have a per cgroup counter on how many pages a cgroup released back to a particular pool? E.g. something which is added up to the same counter on the parent when a cgroup is released.
> >
> > Background is that the pages are not distinguishable from each other, e.g. they are not cache hot or cold or anything like this. So it doesn't matter which pages a cgroup has released but only how many.
> >
> > If it would be possible to get such a counter then it would be like just a few lines of code to add the isolation and still get the advantage of sharing released pages between different cgroups.
> 
> I think numa is the only possible distinction I can see between pages
> here, even uncached GPU access will be slower to further away numa
> nodes,
> 
> But indeed this might be a workable idea, just make something that
> does what list_lru does but just for the counters, and keep the pages
> in a single pool.

If you only want NUMA aware LRU + reclaim/reuse without memcg
awareness, list_lru supports that configuration. Use list_lru_init()
for numa-aware LRU infrastructure, list_lru_init_memcg() should only
be used if need memcg awareness in the LRU.

THere are various caches that use this config e.g. the XFS buffer
cache and dquot caches because they are global caches whose contents
is shared across all cgroups. The shrinker associated with them is
configured only as SHRINKER_NUMA_AWARE so that reclaim is done
per-node rather than as a single global LRU....

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2025-05-28 23:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-26 20:32 list_lru operation for new child memcg? Dave Airlie
2025-05-26 22:08 ` Dave Chinner
2025-05-26 22:30   ` Dave Airlie
2025-05-26 23:49     ` Dave Chinner
2025-05-28  7:20       ` Christian König
2025-05-28 21:53         ` Dave Airlie
2025-05-28 23:20           ` Dave Chinner [this message]
2025-06-02  8:20             ` Christian König

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=aDeaUkvbakteBtZQ@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=airlied@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=nphamcs@gmail.com \
    /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.