diff mbox series

[V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush

Message ID 172547884995.206112.808619042206173396.stgit@firesoul (mailing list archive)
State New
Headers show
Series [V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush | expand

Commit Message

Jesper Dangaard Brouer Sept. 4, 2024, 7:41 p.m. UTC
This patch reintroduces and generalizes the "stats_flush_ongoing" concept to
avoid redundant flushes if there is an ongoing flush at cgroup root level,
addressing production lock contention issues on the global cgroup rstat lock.

At Cloudflare, we observed significant performance degradation due to
lock contention on the rstat lock, primarily caused by kswapd. The
specific mem_cgroup_flush_stats() call inlined in shrink_node, which
takes the rstat lock, is particularly problematic.

On our 12 NUMA node machines, each with a kswapd kthread per NUMA node, we
noted severe lock contention on the rstat lock, causing 12 CPUs to waste
cycles spinning every time kswapd runs. Fleet-wide stats (/proc/N/schedstat)
for kthreads revealed that we are burning an average of 20,000 CPU cores
fleet-wide on kswapd, primarily due to spinning on the rstat lock.

Here's a brief overview of the issue:
- __alloc_pages_slowpath calls wake_all_kswapds, causing all kswapdN threads
  to wake up simultaneously.
- The kswapd thread invokes shrink_node (via balance_pgdat), triggering the
  cgroup rstat flush operation as part of its work.
- balance_pgdat() has a NULL value in target_mem_cgroup, causing
  mem_cgroup_flush_stats() to flush with root_mem_cgroup.

The kernel previously addressed this with a "stats_flush_ongoing" concept,
which was removed in commit 7d7ef0a4686a ("mm: memcg: restore subtree stats
flushing"). This patch reintroduces and generalizes the concept to apply to
all users of cgroup rstat, not just memcg.

In this patch only a root cgroup can become the ongoing flusher, as this solves
the production issue. Letting other levels becoming ongoing flusher cause root
cgroup to contend on the lock again.

Some in-kernel users of the cgroup_rstat_flush() API depend on waiting for the
flush to complete before continuing. This patch introduce the call
cgroup_rstat_flush_relaxed() and use it in those cases that can live with
slightly inaccurate flushes.

This change significantly reduces lock contention, especially in
environments with multiple NUMA nodes, thereby improving overall system
performance.

Fixes: 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing").
Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
---

V9: https://lore.kernel.org/all/172245504313.3147408.12138439169548255896.stgit@firesoul/
V8: https://lore.kernel.org/all/172139415725.3084888.13770938453137383953.stgit@firesoul
V7: https://lore.kernel.org/all/172070450139.2992819.13210624094367257881.stgit@firesoul
V6: https://lore.kernel.org/all/172052399087.2357901.4955042377343593447.stgit@firesoul/
V5: https://lore.kernel.org/all/171956951930.1897969.8709279863947931285.stgit@firesoul/
V4: https://lore.kernel.org/all/171952312320.1810550.13209360603489797077.stgit@firesoul/
V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
V2: https://lore.kernel.org/all/171923011608.1500238.3591002573732683639.stgit@firesoul/
V1: https://lore.kernel.org/all/171898037079.1222367.13467317484793748519.stgit@firesoul/
RFC: https://lore.kernel.org/all/171895533185.1084853.3033751561302228252.stgit@firesoul/

 block/blk-cgroup.c     |    2 +
 include/linux/cgroup.h |    1 +
 kernel/cgroup/rstat.c  |   92 ++++++++++++++++++++++++++++++++++++++++++++----
 mm/memcontrol.c        |    2 +
 4 files changed, 88 insertions(+), 9 deletions(-)

Comments

Yosry Ahmed Sept. 4, 2024, 9:10 p.m. UTC | #1
On Wed, Sep 4, 2024 at 12:41 PM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
> This patch reintroduces and generalizes the "stats_flush_ongoing" concept to
> avoid redundant flushes if there is an ongoing flush at cgroup root level,
> addressing production lock contention issues on the global cgroup rstat lock.
>
> At Cloudflare, we observed significant performance degradation due to
> lock contention on the rstat lock, primarily caused by kswapd. The
> specific mem_cgroup_flush_stats() call inlined in shrink_node, which
> takes the rstat lock, is particularly problematic.
>
> On our 12 NUMA node machines, each with a kswapd kthread per NUMA node, we
> noted severe lock contention on the rstat lock, causing 12 CPUs to waste
> cycles spinning every time kswapd runs. Fleet-wide stats (/proc/N/schedstat)
> for kthreads revealed that we are burning an average of 20,000 CPU cores
> fleet-wide on kswapd, primarily due to spinning on the rstat lock.
>
> Here's a brief overview of the issue:
> - __alloc_pages_slowpath calls wake_all_kswapds, causing all kswapdN threads
>   to wake up simultaneously.
> - The kswapd thread invokes shrink_node (via balance_pgdat), triggering the
>   cgroup rstat flush operation as part of its work.
> - balance_pgdat() has a NULL value in target_mem_cgroup, causing
>   mem_cgroup_flush_stats() to flush with root_mem_cgroup.
>
> The kernel previously addressed this with a "stats_flush_ongoing" concept,
> which was removed in commit 7d7ef0a4686a ("mm: memcg: restore subtree stats
> flushing"). This patch reintroduces and generalizes the concept to apply to
> all users of cgroup rstat, not just memcg.
>
> In this patch only a root cgroup can become the ongoing flusher, as this solves
> the production issue. Letting other levels becoming ongoing flusher cause root
> cgroup to contend on the lock again.
>
> Some in-kernel users of the cgroup_rstat_flush() API depend on waiting for the
> flush to complete before continuing. This patch introduce the call
> cgroup_rstat_flush_relaxed() and use it in those cases that can live with
> slightly inaccurate flushes.
>
> This change significantly reduces lock contention, especially in
> environments with multiple NUMA nodes, thereby improving overall system
> performance.
>
> Fixes: 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing").
> Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>

I am honestly not happy with this patch, see below.

> ---
>

Please include a brief delta vs the previous version here to save
reviewers the duplicated effort of figuring it out.

> V9: https://lore.kernel.org/all/172245504313.3147408.12138439169548255896.stgit@firesoul/
> V8: https://lore.kernel.org/all/172139415725.3084888.13770938453137383953.stgit@firesoul
> V7: https://lore.kernel.org/all/172070450139.2992819.13210624094367257881.stgit@firesoul
> V6: https://lore.kernel.org/all/172052399087.2357901.4955042377343593447.stgit@firesoul/
> V5: https://lore.kernel.org/all/171956951930.1897969.8709279863947931285.stgit@firesoul/
> V4: https://lore.kernel.org/all/171952312320.1810550.13209360603489797077.stgit@firesoul/
> V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
> V2: https://lore.kernel.org/all/171923011608.1500238.3591002573732683639.stgit@firesoul/
> V1: https://lore.kernel.org/all/171898037079.1222367.13467317484793748519.stgit@firesoul/
> RFC: https://lore.kernel.org/all/171895533185.1084853.3033751561302228252.stgit@firesoul/
[..]
> @@ -299,6 +301,67 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
>         spin_unlock_irq(&cgroup_rstat_lock);
>  }
>
> +static inline bool cgroup_is_root(struct cgroup *cgrp)
> +{
> +       return cgroup_parent(cgrp) == NULL;
> +}
> +
> +/**
> + * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
> + * @cgrp: target cgroup
> + *
> + * Function return value follow trylock semantics. Returning true when lock is
> + * obtained. Returning false when not locked and it detected flushing can be
> + * skipped as another ongoing flusher is taking care of the flush.
> + *
> + * For callers that depend on flush completing before returning a strict option
> + * is provided.
> + */
> +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
> +{
> +       struct cgroup *ongoing;
> +
> +       if (strict)
> +               goto lock;
> +
> +       /*
> +        * Check if ongoing flusher is already taking care of this.  Descendant
> +        * check is necessary due to cgroup v1 supporting multiple root's.
> +        */
> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
> +               return false;

Why did we drop the agreed upon method of waiting until the flushers
are done? This is now a much more intrusive patch which makes all
flushers skip if a root is currently flushing. This causes
user-visible problems and is something that I worked hard to fix. I
thought we got good results with waiting for the ongoing flusher as
long as it is a root? What changed?

You also never addressed my concern here about 'ongoing' while we are
accessing it, and never responded to my question in v8 about expanding
this to support non-root cgroups once we shift to a mutex.

I don't appreciate the silent yet drastic change made in this version
and without addressing concerns raised in previous versions. Please
let me know if I missed something.

> +
> +       /* Grab right to be ongoing flusher */
> +       if (!ongoing && cgroup_is_root(cgrp)) {
> +               struct cgroup *old;
> +
> +               old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
> +               if (old) {
> +                       /* Lost race for being ongoing flusher */
> +                       if (cgroup_is_descendant(cgrp, old))
> +                               return false;
> +               }
> +               /* Due to lock yield combined with strict mode record ID */
> +               WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);

I am not sure I understand why we need this, do you mind elaborating?
Jesper Dangaard Brouer Sept. 5, 2024, 2:08 p.m. UTC | #2
On 04/09/2024 23.10, Yosry Ahmed wrote:
> On Wed, Sep 4, 2024 at 12:41 PM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>>
>> This patch reintroduces and generalizes the "stats_flush_ongoing" concept to
>> avoid redundant flushes if there is an ongoing flush at cgroup root level,
>> addressing production lock contention issues on the global cgroup rstat lock.
>>
>> At Cloudflare, we observed significant performance degradation due to
>> lock contention on the rstat lock, primarily caused by kswapd. The
>> specific mem_cgroup_flush_stats() call inlined in shrink_node, which
>> takes the rstat lock, is particularly problematic.
>>
>> On our 12 NUMA node machines, each with a kswapd kthread per NUMA node, we
>> noted severe lock contention on the rstat lock, causing 12 CPUs to waste
>> cycles spinning every time kswapd runs. Fleet-wide stats (/proc/N/schedstat)
>> for kthreads revealed that we are burning an average of 20,000 CPU cores
>> fleet-wide on kswapd, primarily due to spinning on the rstat lock.
>>
>> Here's a brief overview of the issue:
>> - __alloc_pages_slowpath calls wake_all_kswapds, causing all kswapdN threads
>>    to wake up simultaneously.
>> - The kswapd thread invokes shrink_node (via balance_pgdat), triggering the
>>    cgroup rstat flush operation as part of its work.
>> - balance_pgdat() has a NULL value in target_mem_cgroup, causing
>>    mem_cgroup_flush_stats() to flush with root_mem_cgroup.
>>
>> The kernel previously addressed this with a "stats_flush_ongoing" concept,
>> which was removed in commit 7d7ef0a4686a ("mm: memcg: restore subtree stats
>> flushing"). This patch reintroduces and generalizes the concept to apply to
>> all users of cgroup rstat, not just memcg.
>>
>> In this patch only a root cgroup can become the ongoing flusher, as this solves
>> the production issue. Letting other levels becoming ongoing flusher cause root
>> cgroup to contend on the lock again.
>>
>> Some in-kernel users of the cgroup_rstat_flush() API depend on waiting for the
>> flush to complete before continuing. This patch introduce the call
>> cgroup_rstat_flush_relaxed() and use it in those cases that can live with
>> slightly inaccurate flushes.
>>
>> This change significantly reduces lock contention, especially in
>> environments with multiple NUMA nodes, thereby improving overall system
>> performance.
>>
>> Fixes: 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing").
>> Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
> 
> I am honestly not happy with this patch, see below.
> 
>> ---
>>
> 
> Please include a brief delta vs the previous version here to save
> reviewers the duplicated effort of figuring it out.
> 
>> V9: https://lore.kernel.org/all/172245504313.3147408.12138439169548255896.stgit@firesoul/
>> V8: https://lore.kernel.org/all/172139415725.3084888.13770938453137383953.stgit@firesoul
>> V7: https://lore.kernel.org/all/172070450139.2992819.13210624094367257881.stgit@firesoul
>> V6: https://lore.kernel.org/all/172052399087.2357901.4955042377343593447.stgit@firesoul/
>> V5: https://lore.kernel.org/all/171956951930.1897969.8709279863947931285.stgit@firesoul/
>> V4: https://lore.kernel.org/all/171952312320.1810550.13209360603489797077.stgit@firesoul/
>> V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
>> V2: https://lore.kernel.org/all/171923011608.1500238.3591002573732683639.stgit@firesoul/
>> V1: https://lore.kernel.org/all/171898037079.1222367.13467317484793748519.stgit@firesoul/
>> RFC: https://lore.kernel.org/all/171895533185.1084853.3033751561302228252.stgit@firesoul/
> [..]
>> @@ -299,6 +301,67 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
>>          spin_unlock_irq(&cgroup_rstat_lock);
>>   }
>>
>> +static inline bool cgroup_is_root(struct cgroup *cgrp)
>> +{
>> +       return cgroup_parent(cgrp) == NULL;
>> +}
>> +
>> +/**
>> + * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
>> + * @cgrp: target cgroup
>> + *
>> + * Function return value follow trylock semantics. Returning true when lock is
>> + * obtained. Returning false when not locked and it detected flushing can be
>> + * skipped as another ongoing flusher is taking care of the flush.
>> + *
>> + * For callers that depend on flush completing before returning a strict option
>> + * is provided.
>> + */
>> +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
>> +{
>> +       struct cgroup *ongoing;
>> +
>> +       if (strict)
>> +               goto lock;
>> +
>> +       /*
>> +        * Check if ongoing flusher is already taking care of this.  Descendant
>> +        * check is necessary due to cgroup v1 supporting multiple root's.
>> +        */
>> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
>> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
>> +               return false;
> 
> Why did we drop the agreed upon method of waiting until the flushers
> are done? This is now a much more intrusive patch which makes all
> flushers skip if a root is currently flushing. This causes
> user-visible problems and is something that I worked hard to fix. I
> thought we got good results with waiting for the ongoing flusher as
> long as it is a root? What changed?
> 

I disagree with the idea of waiting until the flusher is done.
As Shakeel have pointed out before, we don't need accurate stats.
This caused issues and 'completions' complicated the code too much.

When multiple (12) kswapd's are running, then waiting for ongoing
flusher will cause us to delay all other kswapd threads, for on my
production system approx 24 ms (see attached prod graph).
Matt (Cc) is currently[1] looking into page alloc failures that are
happening across the fleet, when NIC RX packets as those allocs are
GFP_ATOMIC.  So, basically kswapd isn't reclaiming memory fast enough on
our systems, which could be related to this flush latency.  (Quick calc,
prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are
handled, that exceed RX ring size 1024).

  [1] 
https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/

For this reason, I don't want to have code that waits for ongoing
flushers to finish.  This is why I changed the code.


> You also never addressed my concern here about 'ongoing' while we are
> accessing it, and never responded to my question in v8 about expanding
> this to support non-root cgroups once we shift to a mutex.
> 

I don't think we should expand this to non-root cgroups.  My production
data from this V10 shows we don't need this for non-root cgroups.


> I don't appreciate the silent yet drastic change made in this version
> and without addressing concerns raised in previous versions. Please
> let me know if I missed something.
>

IMHO we needed a drastic change, because patch was getting too
complicated, and my production experiments showed that it was no-longer
solving the contention issue (due to allowing non-root cgroups to become
ongoing).

Production servers with this V10 patch applied shows HUGE improvements.
Let me grab a graf showing level-0 contention events being reduced from
1360 event/sec to 0.277 events/sec.  I had to change to a log-scale graf
to make improvement visible.  The wait-time is also basically gone.  The
improvements are so convincing and highly needed, that we are going to
deploy this improvement.  I usually have a very strong upstream first
principle, but we simply cannot wait any-longer for a solution to this
production issue.


>> +
>> +       /* Grab right to be ongoing flusher */
>> +       if (!ongoing && cgroup_is_root(cgrp)) {
>> +               struct cgroup *old;
>> +
>> +               old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
>> +               if (old) {
>> +                       /* Lost race for being ongoing flusher */
>> +                       if (cgroup_is_descendant(cgrp, old))
>> +                               return false;
>> +               }
>> +               /* Due to lock yield combined with strict mode record ID */
>> +               WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
> 
> I am not sure I understand why we need this, do you mind elaborating?

Let me expand the comment. Due to lock yield an ongoing (root) flusher
can yield the lock, which would allow a root flush in strict mode to
obtain the lock, which then in the unlock call (see below) will clear
cgrp_rstat_ongoing_flusher (as cgrp in both cases have "root" cgrp ptr),
unless it have this flush_ID to tell them apart.

[...]
 > +static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp)
 > +{
 > +	if (cgrp == READ_ONCE(cgrp_rstat_ongoing_flusher) &&
 > +	    READ_ONCE(cgrp_rstat_ongoing_flusher_ID) == current) {
 > +		WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, NULL);
 > +		WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL);
 > +	}
 > +
 > +	__cgroup_rstat_unlock(cgrp, -1);
 > +}

--Jesper
Yosry Ahmed Sept. 5, 2024, 5:31 p.m. UTC | #3
[..]
> >> @@ -299,6 +301,67 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
> >>          spin_unlock_irq(&cgroup_rstat_lock);
> >>   }
> >>
> >> +static inline bool cgroup_is_root(struct cgroup *cgrp)
> >> +{
> >> +       return cgroup_parent(cgrp) == NULL;
> >> +}
> >> +
> >> +/**
> >> + * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
> >> + * @cgrp: target cgroup
> >> + *
> >> + * Function return value follow trylock semantics. Returning true when lock is
> >> + * obtained. Returning false when not locked and it detected flushing can be
> >> + * skipped as another ongoing flusher is taking care of the flush.
> >> + *
> >> + * For callers that depend on flush completing before returning a strict option
> >> + * is provided.
> >> + */
> >> +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
> >> +{
> >> +       struct cgroup *ongoing;
> >> +
> >> +       if (strict)
> >> +               goto lock;
> >> +
> >> +       /*
> >> +        * Check if ongoing flusher is already taking care of this.  Descendant
> >> +        * check is necessary due to cgroup v1 supporting multiple root's.
> >> +        */
> >> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
> >> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
> >> +               return false;
> >
> > Why did we drop the agreed upon method of waiting until the flushers
> > are done? This is now a much more intrusive patch which makes all
> > flushers skip if a root is currently flushing. This causes
> > user-visible problems and is something that I worked hard to fix. I
> > thought we got good results with waiting for the ongoing flusher as
> > long as it is a root? What changed?
> >
>
> I disagree with the idea of waiting until the flusher is done.
> As Shakeel have pointed out before, we don't need accurate stats.
> This caused issues and 'completions' complicated the code too much.

I think Shakeel was referring specifically to the flush in the reclaim
path. I don't think this statement holds for all cgroup flushers,
especially those exposed to userspace.

>
> When multiple (12) kswapd's are running, then waiting for ongoing
> flusher will cause us to delay all other kswapd threads, for on my
> production system approx 24 ms (see attached prod graph).
> Matt (Cc) is currently[1] looking into page alloc failures that are
> happening across the fleet, when NIC RX packets as those allocs are
> GFP_ATOMIC.  So, basically kswapd isn't reclaiming memory fast enough on
> our systems, which could be related to this flush latency.  (Quick calc,
> prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are
> handled, that exceed RX ring size 1024).
>
>   [1]
> https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/
>
> For this reason, I don't want to have code that waits for ongoing
> flushers to finish.  This is why I changed the code.

My understanding was that the previous versions solved most of the
problem. However, if it's not enough and we need to completely skip
the flush, then I don't think this patch is the right way to go. This
affects all flushers, not just the reclaim path, and not even just the
memcg flushers. Waiting for ongoing flushers was a generic approach
that should work for all flushers, but completely skipping the flush
is not.

If your problem is specifically the flush in the reclaim path, then
Shakeel's patch to replace that flush with the ratelimited version
should fix your problem. It was already merged into mm-stable (so
headed toward v6.11 AFAICT).

>
>
> > You also never addressed my concern here about 'ongoing' while we are
> > accessing it, and never responded to my question in v8 about expanding
> > this to support non-root cgroups once we shift to a mutex.
> >
>
> I don't think we should expand this to non-root cgroups.  My production
> data from this V10 shows we don't need this for non-root cgroups.

Right, because you are concerned with the flush in the kswapd path
specifically. This patch touches affects much more than that.

>
>
> > I don't appreciate the silent yet drastic change made in this version
> > and without addressing concerns raised in previous versions. Please
> > let me know if I missed something.
> >
>
> IMHO we needed a drastic change, because patch was getting too
> complicated, and my production experiments showed that it was no-longer
> solving the contention issue (due to allowing non-root cgroups to become
> ongoing).

I thought we agreed to wait for the ongoing flusher to complete, but
only allow root cgroups to become the ongoing flusher (at least
initially). Not sure what changed.

>
> Production servers with this V10 patch applied shows HUGE improvements.
> Let me grab a graf showing level-0 contention events being reduced from
> 1360 event/sec to 0.277 events/sec.  I had to change to a log-scale graf
> to make improvement visible.  The wait-time is also basically gone.  The
> improvements are so convincing and highly needed, that we are going to
> deploy this improvement.  I usually have a very strong upstream first
> principle, but we simply cannot wait any-longer for a solution to this
> production issue.

Of course there is a huge improvement, you are completely skipping the
flush :) You are gaining a lot of performance but you'll also lose
something, there is no free lunch here. This may be an acceptable
tradeoff for the reclaim path, but definitely not for all flushers.

>
>
> >> +
> >> +       /* Grab right to be ongoing flusher */
> >> +       if (!ongoing && cgroup_is_root(cgrp)) {
> >> +               struct cgroup *old;
> >> +
> >> +               old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
> >> +               if (old) {
> >> +                       /* Lost race for being ongoing flusher */
> >> +                       if (cgroup_is_descendant(cgrp, old))
> >> +                               return false;
> >> +               }
> >> +               /* Due to lock yield combined with strict mode record ID */
> >> +               WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
> >
> > I am not sure I understand why we need this, do you mind elaborating?
>
> Let me expand the comment. Due to lock yield an ongoing (root) flusher
> can yield the lock, which would allow a root flush in strict mode to
> obtain the lock, which then in the unlock call (see below) will clear
> cgrp_rstat_ongoing_flusher (as cgrp in both cases have "root" cgrp ptr),
> unless it have this flush_ID to tell them apart.

The pointers should be different for different roots though, right?
Why do we need the ID to tell them apart? I am not sure I follow.
kernel test robot Sept. 5, 2024, 8:20 p.m. UTC | #4
Hi Jesper,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tj-cgroup/for-next]
[also build test WARNING on axboe-block/for-next akpm-mm/mm-everything linus/master v6.11-rc6 next-20240905]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jesper-Dangaard-Brouer/cgroup-rstat-Avoid-flushing-if-there-is-an-ongoing-root-flush/20240905-034221
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
patch link:    https://lore.kernel.org/r/172547884995.206112.808619042206173396.stgit%40firesoul
patch subject: [PATCH V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush
config: parisc-defconfig (https://download.01.org/0day-ci/archive/20240906/202409060400.Z4B69Z8T-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240906/202409060400.Z4B69Z8T-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409060400.Z4B69Z8T-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> kernel/cgroup/rstat.c:321: warning: Function parameter or struct member 'strict' not described in 'cgroup_rstat_trylock_flusher'


vim +321 kernel/cgroup/rstat.c

   308	
   309	/**
   310	 * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
   311	 * @cgrp: target cgroup
   312	 *
   313	 * Function return value follow trylock semantics. Returning true when lock is
   314	 * obtained. Returning false when not locked and it detected flushing can be
   315	 * skipped as another ongoing flusher is taking care of the flush.
   316	 *
   317	 * For callers that depend on flush completing before returning a strict option
   318	 * is provided.
   319	 */
   320	static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
 > 321	{
   322		struct cgroup *ongoing;
   323	
   324		if (strict)
   325			goto lock;
   326	
   327		/*
   328		 * Check if ongoing flusher is already taking care of this.  Descendant
   329		 * check is necessary due to cgroup v1 supporting multiple root's.
   330		 */
   331		ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
   332		if (ongoing && cgroup_is_descendant(cgrp, ongoing))
   333			return false;
   334	
   335		/* Grab right to be ongoing flusher */
   336		if (!ongoing && cgroup_is_root(cgrp)) {
   337			struct cgroup *old;
   338	
   339			old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
   340			if (old) {
   341				/* Lost race for being ongoing flusher */
   342				if (cgroup_is_descendant(cgrp, old))
   343					return false;
   344			}
   345			/* Due to lock yield combined with strict mode record ID */
   346			WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
   347		}
   348	lock:
   349		__cgroup_rstat_lock(cgrp, -1);
   350	
   351		return true;
   352	}
   353
kernel test robot Sept. 10, 2024, 5:23 a.m. UTC | #5
Hi Jesper,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tj-cgroup/for-next]
[also build test WARNING on axboe-block/for-next akpm-mm/mm-everything linus/master v6.11-rc7 next-20240909]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jesper-Dangaard-Brouer/cgroup-rstat-Avoid-flushing-if-there-is-an-ongoing-root-flush/20240905-034221
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
patch link:    https://lore.kernel.org/r/172547884995.206112.808619042206173396.stgit%40firesoul
patch subject: [PATCH V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush
config: hexagon-randconfig-r121-20240910 (https://download.01.org/0day-ci/archive/20240910/202409101356.VXPFCu6l-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce: (https://download.01.org/0day-ci/archive/20240910/202409101356.VXPFCu6l-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409101356.VXPFCu6l-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> kernel/cgroup/rstat.c:339:23: sparse: sparse: Using plain integer as NULL pointer
   kernel/cgroup/rstat.c:87:18: sparse: sparse: context imbalance in 'cgroup_rstat_updated' - different lock contexts for basic block
   kernel/cgroup/rstat.c:75:9: sparse: sparse: context imbalance in 'cgroup_rstat_updated_list' - wrong count at exit
   kernel/cgroup/rstat.c:320:13: sparse: sparse: context imbalance in 'cgroup_rstat_trylock_flusher' - wrong count at exit
   kernel/cgroup/rstat.c:300:34: sparse: sparse: context imbalance in 'cgroup_rstat_unlock_flusher' - unexpected unlock
   kernel/cgroup/rstat.c:373:9: sparse: sparse: context imbalance in 'cgroup_rstat_flush_locked' - different lock contexts for basic block
   kernel/cgroup/rstat.c:447:9: sparse: sparse: context imbalance in 'cgroup_rstat_flush_hold' - wrong count at exit
   kernel/cgroup/rstat.c:457:6: sparse: sparse: context imbalance in 'cgroup_rstat_flush_release' - wrong count at exit

vim +339 kernel/cgroup/rstat.c

   308	
   309	/**
   310	 * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
   311	 * @cgrp: target cgroup
   312	 *
   313	 * Function return value follow trylock semantics. Returning true when lock is
   314	 * obtained. Returning false when not locked and it detected flushing can be
   315	 * skipped as another ongoing flusher is taking care of the flush.
   316	 *
   317	 * For callers that depend on flush completing before returning a strict option
   318	 * is provided.
   319	 */
   320	static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
   321	{
   322		struct cgroup *ongoing;
   323	
   324		if (strict)
   325			goto lock;
   326	
   327		/*
   328		 * Check if ongoing flusher is already taking care of this.  Descendant
   329		 * check is necessary due to cgroup v1 supporting multiple root's.
   330		 */
   331		ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
   332		if (ongoing && cgroup_is_descendant(cgrp, ongoing))
   333			return false;
   334	
   335		/* Grab right to be ongoing flusher */
   336		if (!ongoing && cgroup_is_root(cgrp)) {
   337			struct cgroup *old;
   338	
 > 339			old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
   340			if (old) {
   341				/* Lost race for being ongoing flusher */
   342				if (cgroup_is_descendant(cgrp, old))
   343					return false;
   344			}
   345			/* Due to lock yield combined with strict mode record ID */
   346			WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
   347		}
   348	lock:
   349		__cgroup_rstat_lock(cgrp, -1);
   350	
   351		return true;
   352	}
   353
Jesper Dangaard Brouer Sept. 10, 2024, 2:16 p.m. UTC | #6
On 05/09/2024 19.31, Yosry Ahmed wrote:
> [..]
>>>> @@ -299,6 +301,67 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
>>>>           spin_unlock_irq(&cgroup_rstat_lock);
>>>>    }
>>>>
>>>> +static inline bool cgroup_is_root(struct cgroup *cgrp)
>>>> +{
>>>> +       return cgroup_parent(cgrp) == NULL;
>>>> +}
>>>> +
>>>> +/**
>>>> + * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
>>>> + * @cgrp: target cgroup
>>>> + *
>>>> + * Function return value follow trylock semantics. Returning true when lock is
>>>> + * obtained. Returning false when not locked and it detected flushing can be
>>>> + * skipped as another ongoing flusher is taking care of the flush.
>>>> + *
>>>> + * For callers that depend on flush completing before returning a strict option
>>>> + * is provided.
>>>> + */
>>>> +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
>>>> +{
>>>> +       struct cgroup *ongoing;
>>>> +
>>>> +       if (strict)
>>>> +               goto lock;
>>>> +
>>>> +       /*
>>>> +        * Check if ongoing flusher is already taking care of this.  Descendant
>>>> +        * check is necessary due to cgroup v1 supporting multiple root's.
>>>> +        */
>>>> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
>>>> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
>>>> +               return false;
>>>
>>> Why did we drop the agreed upon method of waiting until the flushers
>>> are done? This is now a much more intrusive patch which makes all
>>> flushers skip if a root is currently flushing. This causes
>>> user-visible problems and is something that I worked hard to fix. I
>>> thought we got good results with waiting for the ongoing flusher as
>>> long as it is a root? What changed?
>>>
>>
>> I disagree with the idea of waiting until the flusher is done.
>> As Shakeel have pointed out before, we don't need accurate stats.
>> This caused issues and 'completions' complicated the code too much.
> 
> I think Shakeel was referring specifically to the flush in the reclaim
> path. I don't think this statement holds for all cgroup flushers,
> especially those exposed to userspace.
>

My userspace readers (of /sys/fs/cgroup/*/*/memory.stat) are primarily
cadvisor and systemd, which doesn't need this accuracy.

Can you explain your userspace use-case that need this accuracy?

I assume you are primarily focused on memory.stat?
Can we slack on accuracy for io.stat and cpu.stat?

Detail: reading cpu.stat already waits on the ongoing flusher by always
taking the lock (as it use lock to protect other things).  This
indirectly created what you are asking for... If your userspace program
first reads cpu.stat, then it will serve as a barrier that waits for the
ongoing flusher.

Could we have a sysctl that enabled "accurate" cgroup rstat reading?
As most users don't need this high accuracy.


>>
>> When multiple (12) kswapd's are running, then waiting for ongoing
>> flusher will cause us to delay all other kswapd threads, for on my
>> production system approx 24 ms (see attached prod graph).
>> Matt (Cc) is currently[1] looking into page alloc failures that are
>> happening across the fleet, when NIC RX packets as those allocs are
>> GFP_ATOMIC.  So, basically kswapd isn't reclaiming memory fast enough on
>> our systems, which could be related to this flush latency.  (Quick calc,
>> prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are
>> handled, that exceed RX ring size 1024).
>>
>>    [1]
>> https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/
>>
>> For this reason, I don't want to have code that waits for ongoing
>> flushers to finish.  This is why I changed the code.
> 
> My understanding was that the previous versions solved most of the
> problem. However, if it's not enough and we need to completely skip
> the flush, then I don't think this patch is the right way to go. This
> affects all flushers, not just the reclaim path, and not even just the
> memcg flushers. Waiting for ongoing flushers was a generic approach
> that should work for all flushers, but completely skipping the flush
> is not.
> 

IMHO waiting for ongoing flushers was not a good idea, as it caused
other issues. Letting 11 other kswapd wait 24 ms for a single kswapd
thread was not good for our production systems.

I need remind people that "completely skipping the flush" due to ongoing
flusher have worked well for us before kernel v6.8 (before commit
7d7ef0a4686a).  So, I really don't see skipping the flush, when there is
an ongoing flusher is that controversial.

I think it is controversial to *wait* for the ongoing flusher as that
IMHO defeats the whole purpose of having an ongoing flusher... then we
could just have a normal mutex lock if we want to wait.


> If your problem is specifically the flush in the reclaim path, then
> Shakeel's patch to replace that flush with the ratelimited version
> should fix your problem. It was already merged into mm-stable (so
> headed toward v6.11 AFAICT).
> 
>>
>>
>>> You also never addressed my concern here about 'ongoing' while we are
>>> accessing it, and never responded to my question in v8 about expanding
>>> this to support non-root cgroups once we shift to a mutex.
>>>
>>
>> I don't think we should expand this to non-root cgroups.  My production
>> data from this V10 shows we don't need this for non-root cgroups.
> 
> Right, because you are concerned with the flush in the kswapd path
> specifically. This patch touches affects much more than that.
> 

It is not only the flush in the kswapd path that concerns me.
My other concern is userspace cadvisor that periodically reads ALL the
.stat files on the system and creates flush spikes (every minute).  When
advisor collides with root-cgroup flush (either 2 sec periodic or
kswapd) then bad interactions happens in prod.

>>
>>
>>> I don't appreciate the silent yet drastic change made in this version
>>> and without addressing concerns raised in previous versions. Please
>>> let me know if I missed something.
>>>
>>
>> IMHO we needed a drastic change, because patch was getting too
>> complicated, and my production experiments showed that it was no-longer
>> solving the contention issue (due to allowing non-root cgroups to become
>> ongoing).
> 
> I thought we agreed to wait for the ongoing flusher to complete, but
> only allow root cgroups to become the ongoing flusher (at least
> initially). Not sure what changed.
> 

Practical implementation (with completions) and production experiments
is what changed my mind. Thus, I no-longer agree that waiting for the
ongoing flusher to complete is the right solution.


>>
>> Production servers with this V10 patch applied shows HUGE improvements.
>> Let me grab a graf showing level-0 contention events being reduced from
>> 1360 event/sec to 0.277 events/sec.  I had to change to a log-scale graf
>> to make improvement visible.  The wait-time is also basically gone.  The
>> improvements are so convincing and highly needed, that we are going to
>> deploy this improvement.  I usually have a very strong upstream first
>> principle, but we simply cannot wait any-longer for a solution to this
>> production issue.
> 
> Of course there is a huge improvement, you are completely skipping the
> flush :) You are gaining a lot of performance but you'll also lose
> something, there is no free lunch here. This may be an acceptable
> tradeoff for the reclaim path, but definitely not for all flushers.
> 

To move forward, can you please list the flushers that cannot accept 
this trade off?
Then I can exclude these in the next version.

>>
>>
>>>> +
>>>> +       /* Grab right to be ongoing flusher */
>>>> +       if (!ongoing && cgroup_is_root(cgrp)) {
>>>> +               struct cgroup *old;
>>>> +
>>>> +               old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
>>>> +               if (old) {
>>>> +                       /* Lost race for being ongoing flusher */
>>>> +                       if (cgroup_is_descendant(cgrp, old))
>>>> +                               return false;
>>>> +               }
>>>> +               /* Due to lock yield combined with strict mode record ID */
>>>> +               WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
>>>
>>> I am not sure I understand why we need this, do you mind elaborating?
>>
>> Let me expand the comment. Due to lock yield an ongoing (root) flusher
>> can yield the lock, which would allow a root flush in strict mode to
>> obtain the lock, which then in the unlock call (see below) will clear
>> cgrp_rstat_ongoing_flusher (as cgrp in both cases have "root" cgrp ptr),
>> unless it have this flush_ID to tell them apart.
> 
> The pointers should be different for different roots though, right?
> Why do we need the ID to tell them apart? I am not sure I follow.

It is not different roots, it is needed for "the-same" root.

It is possible that while an ongoing flusher is working, another process
can call the flush in "strict" mode (for same root cgroup), that will
bypass the ongoing check, and it will be waiting for the lock.  The
ongoing flusher chooses to yield the lock, letting in the strict-mode
flusher that then clears the ongoing flusher, unless we add this ID
check.  I hope it is more clear now.

--Jesper
Yosry Ahmed Sept. 10, 2024, 6:55 p.m. UTC | #7
[..]
>
> >>>> +       /*
> >>>> +        * Check if ongoing flusher is already taking care of this.  Descendant
> >>>> +        * check is necessary due to cgroup v1 supporting multiple root's.
> >>>> +        */
> >>>> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
> >>>> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
> >>>> +               return false;
> >>>
> >>> Why did we drop the agreed upon method of waiting until the flushers
> >>> are done? This is now a much more intrusive patch which makes all
> >>> flushers skip if a root is currently flushing. This causes
> >>> user-visible problems and is something that I worked hard to fix. I
> >>> thought we got good results with waiting for the ongoing flusher as
> >>> long as it is a root? What changed?
> >>>
> >>
> >> I disagree with the idea of waiting until the flusher is done.
> >> As Shakeel have pointed out before, we don't need accurate stats.
> >> This caused issues and 'completions' complicated the code too much.
> >
> > I think Shakeel was referring specifically to the flush in the reclaim
> > path. I don't think this statement holds for all cgroup flushers,
> > especially those exposed to userspace.
> >
>
> My userspace readers (of /sys/fs/cgroup/*/*/memory.stat) are primarily
> cadvisor and systemd, which doesn't need this accuracy.
>
> Can you explain your userspace use-case that need this accuracy?


Please look at the commit log of this patch [1] that removed
stats_flush_ongoing (the one in Fixes).

[1]https://lore.kernel.org/lkml/20231129032154.3710765-6-yosryahmed@google.com/

>
>
> I assume you are primarily focused on memory.stat?
> Can we slack on accuracy for io.stat and cpu.stat?


I feel like this will eventually also cause problems as it is a
user-visible change, but I can't tell for sure.

>
>
> Detail: reading cpu.stat already waits on the ongoing flusher by always
> taking the lock (as it use lock to protect other things).  This
> indirectly created what you are asking for... If your userspace program
> first reads cpu.stat, then it will serve as a barrier that waits for the
> ongoing flusher.


Making userspace programs read cpu.stat before memory.stat to get the
correct flushing behavior is certainly not the way to address this
imo.

>
>
> Could we have a sysctl that enabled "accurate" cgroup rstat reading?
> As most users don't need this high accuracy.


I did a lot of testing of flushing latency in the commit I referred to
above, you'll find numbers there. I think the problem for you mainly
comes from having 12 kswapd threads flushing the root, they compete
among one another as well as with userspace reads. Shakeel's patch
should address this, and honestly I think the longer-term approach
should be to eliminate all in-kernel flushers [2], rather than making
all flushers inaccurate.

[2]https://lore.kernel.org/lkml/CAJD7tkaBfWWS32VYAwkgyfzkD_WbUUbx+rrK-Cc6OT7UN27DYA@mail.gmail.com/

>
>
>
> >>
> >> When multiple (12) kswapd's are running, then waiting for ongoing
> >> flusher will cause us to delay all other kswapd threads, for on my
> >> production system approx 24 ms (see attached prod graph).
> >> Matt (Cc) is currently[1] looking into page alloc failures that are
> >> happening across the fleet, when NIC RX packets as those allocs are
> >> GFP_ATOMIC.  So, basically kswapd isn't reclaiming memory fast enough on
> >> our systems, which could be related to this flush latency.  (Quick calc,
> >> prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are
> >> handled, that exceed RX ring size 1024).
> >>
> >>    [1]
> >> https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/
> >>
> >> For this reason, I don't want to have code that waits for ongoing
> >> flushers to finish.  This is why I changed the code.
> >
> > My understanding was that the previous versions solved most of the
> > problem. However, if it's not enough and we need to completely skip
> > the flush, then I don't think this patch is the right way to go. This
> > affects all flushers, not just the reclaim path, and not even just the
> > memcg flushers. Waiting for ongoing flushers was a generic approach
> > that should work for all flushers, but completely skipping the flush
> > is not.
> >
>
> IMHO waiting for ongoing flushers was not a good idea, as it caused
> other issues. Letting 11 other kswapd wait 24 ms for a single kswapd
> thread was not good for our production systems.


If it takes one kswapd thread 24 ms to flush the stats, then that's
the raw flush time. If all 12 kswapd threads started at different
times they would all spend 24 ms flushing anyway, so waiting for the
ongoing flusher is not a regression or a newly introduced delay. The
ongoing flusher mechanism rather tries to optimize this by avoiding
the lock contention and waiting for the ongoing flusher rather than
competing on the lock and redoing some of the work.

>
>
> I need remind people that "completely skipping the flush" due to ongoing
> flusher have worked well for us before kernel v6.8 (before commit
> 7d7ef0a4686a). So, I really don't see skipping the flush, when there is
> an ongoing flusher is that controversial.


Skipping the flush was introduced in v5.15 as part of aa48e47e3906
("memcg: infrastructure to flush memcg stats"). Before then, reading
the stats from userspace was as accurate as possible. When we moved to
a kernel with that commit we noticed the regression. So it wasn't
always the case that userspace reads were inaccurate or did not flush.

>
>
> I think it is controversial to *wait* for the ongoing flusher as that
> IMHO defeats the whole purpose of having an ongoing flusher...


The point of having an ongoing flusher is to avoid reacquiring the
lock after they are done, and checking all the percpu trees again for
updates, which would be a waste of work and unnecessary contention on
the lock. It's definitely an improvement over directly competing over
the lock, yet it doesn't sacrifice accuracy.

>
> then we could just have a normal mutex lock if we want to wait.


I am not against using a mutex as I mentioned before. If there are
concerns about priority inversions we can add a timeout as we
discussed. The ongoing flusher mechanism is similar in principle to a
mutex, the advantage is that whoever holds the lock does not sleep, so
it gets the flush done faster and waiters wake up faster.

>
>
>
> > If your problem is specifically the flush in the reclaim path, then
> > Shakeel's patch to replace that flush with the ratelimited version
> > should fix your problem. It was already merged into mm-stable (so
> > headed toward v6.11 AFAICT).
> >
> >>
> >>
> >>> You also never addressed my concern here about 'ongoing' while we are
> >>> accessing it, and never responded to my question in v8 about expanding
> >>> this to support non-root cgroups once we shift to a mutex.
> >>>
> >>
> >> I don't think we should expand this to non-root cgroups.  My production
> >> data from this V10 shows we don't need this for non-root cgroups.
> >
> > Right, because you are concerned with the flush in the kswapd path
> > specifically. This patch touches affects much more than that.
> >
>
> It is not only the flush in the kswapd path that concerns me.
> My other concern is userspace cadvisor that periodically reads ALL the
> .stat files on the system and creates flush spikes (every minute).  When
> advisor collides with root-cgroup flush (either 2 sec periodic or
> kswapd) then bad interactions happens in prod.


I believe the problem here is the kswapd flushers competing with
cadvisor userspace read. I don't think the periodic flusher that runs
every 2s colliding with the cadvisor reader that runs every minute
would really cause a problem. Also both of these paths should not be
latency sensitive anyway. So again, Shakeel's patch should help here.

Did you check if Shakeel's patch fixes your problem?

>
>
> >>
> >>
> >>> I don't appreciate the silent yet drastic change made in this version
> >>> and without addressing concerns raised in previous versions. Please
> >>> let me know if I missed something.
> >>>
> >>
> >> IMHO we needed a drastic change, because patch was getting too
> >> complicated, and my production experiments showed that it was no-longer
> >> solving the contention issue (due to allowing non-root cgroups to become
> >> ongoing).
> >
> > I thought we agreed to wait for the ongoing flusher to complete, but
> > only allow root cgroups to become the ongoing flusher (at least
> > initially). Not sure what changed.
> >
>
> Practical implementation (with completions) and production experiments
> is what changed my mind. Thus, I no-longer agree that waiting for the
> ongoing flusher to complete is the right solution.


My understanding based on [1] was that the ongoing flusher mechanism
with only root flushers fixed the problem, but maybe you got more data
afterward.

[1]https://lore.kernel.org/lkml/ee0f7d29-1385-4799-ab4b-6080ca7fd74b@kernel.org/

>
>
>
> >>
> >> Production servers with this V10 patch applied shows HUGE improvements.
> >> Let me grab a graf showing level-0 contention events being reduced from
> >> 1360 event/sec to 0.277 events/sec.  I had to change to a log-scale graf
> >> to make improvement visible.  The wait-time is also basically gone.  The
> >> improvements are so convincing and highly needed, that we are going to
> >> deploy this improvement.  I usually have a very strong upstream first
> >> principle, but we simply cannot wait any-longer for a solution to this
> >> production issue.
> >
> > Of course there is a huge improvement, you are completely skipping the
> > flush :) You are gaining a lot of performance but you'll also lose
> > something, there is no free lunch here. This may be an acceptable
> > tradeoff for the reclaim path, but definitely not for all flushers.
> >
>
> To move forward, can you please list the flushers that cannot accept
> this trade off?
> Then I can exclude these in the next version.


I am not sure which flushers would be problematic, I have seen
problems with the memcg userspace readers, but this doesn't mean it's
the only source of problems. There is also a flush in the zswap path
for charging that may be affected, but we discussed moving that to a
completely different approach to avoid the flush.

I am against skipping the flush for all cases with exceptions. What
Shakeel did was the opposite and the less controversial approach, skip
the flush only for the reclaim path because it's the one we observed
causing problems.

>
>
> >>
> >>
> >>>> +
> >>>> +       /* Grab right to be ongoing flusher */
> >>>> +       if (!ongoing && cgroup_is_root(cgrp)) {
> >>>> +               struct cgroup *old;
> >>>> +
> >>>> +               old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
> >>>> +               if (old) {
> >>>> +                       /* Lost race for being ongoing flusher */
> >>>> +                       if (cgroup_is_descendant(cgrp, old))
> >>>> +                               return false;
> >>>> +               }
> >>>> +               /* Due to lock yield combined with strict mode record ID */
> >>>> +               WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
> >>>
> >>> I am not sure I understand why we need this, do you mind elaborating?
> >>
> >> Let me expand the comment. Due to lock yield an ongoing (root) flusher
> >> can yield the lock, which would allow a root flush in strict mode to
> >> obtain the lock, which then in the unlock call (see below) will clear
> >> cgrp_rstat_ongoing_flusher (as cgrp in both cases have "root" cgrp ptr),
> >> unless it have this flush_ID to tell them apart.
> >
> > The pointers should be different for different roots though, right?
> > Why do we need the ID to tell them apart? I am not sure I follow.
>
> It is not different roots, it is needed for "the-same" root.
>
> It is possible that while an ongoing flusher is working, another process
> can call the flush in "strict" mode (for same root cgroup), that will
> bypass the ongoing check, and it will be waiting for the lock.  The
> ongoing flusher chooses to yield the lock, letting in the strict-mode
> flusher that then clears the ongoing flusher, unless we add this ID
> check.  I hope it is more clear now.
>
> --Jesper
Jesper Dangaard Brouer Sept. 12, 2024, 3:41 p.m. UTC | #8
On 10/09/2024 20.55, Yosry Ahmed wrote:
> [..]
>>
>>>>>> +       /*
>>>>>> +        * Check if ongoing flusher is already taking care of this.  Descendant
>>>>>> +        * check is necessary due to cgroup v1 supporting multiple root's.
>>>>>> +        */
>>>>>> +       ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
>>>>>> +       if (ongoing && cgroup_is_descendant(cgrp, ongoing))
>>>>>> +               return false;
>>>>>
>>>>> Why did we drop the agreed upon method of waiting until the flushers
>>>>> are done? This is now a much more intrusive patch which makes all
>>>>> flushers skip if a root is currently flushing. This causes
>>>>> user-visible problems and is something that I worked hard to fix. I
>>>>> thought we got good results with waiting for the ongoing flusher as
>>>>> long as it is a root? What changed?
>>>>>
>>>>
>>>> I disagree with the idea of waiting until the flusher is done.
>>>> As Shakeel have pointed out before, we don't need accurate stats.
>>>> This caused issues and 'completions' complicated the code too much.
>>>
>>> I think Shakeel was referring specifically to the flush in the reclaim
>>> path. I don't think this statement holds for all cgroup flushers,
>>> especially those exposed to userspace.
>>>
>>
>> My userspace readers (of /sys/fs/cgroup/*/*/memory.stat) are primarily
>> cadvisor and systemd, which doesn't need this accuracy.
>>
>> Can you explain your userspace use-case that need this accuracy?
> 
> 
> Please look at the commit log of this patch [1] that removed
> stats_flush_ongoing (the one in Fixes).
> 
> [1]https://lore.kernel.org/lkml/20231129032154.3710765-6-yosryahmed@google.com/
> 

I think I understand the inaccuracy concern now.  So, it is the 2 second
periodic flush that is the concern.  That can cause up-to 2 seconds old
data to be read by userspace, when read contend with ongoing root
flusher (if it doesn't wait for the flush).  I agree, that 2 sec old
data is too inaccurate.

I'm coding V11 that will "wait_for_flush" in the userspace call paths.

>>
>>
>> I assume you are primarily focused on memory.stat?
>> Can we slack on accuracy for io.stat and cpu.stat?
> 
> 
> I feel like this will eventually also cause problems as it is a
> user-visible change, but I can't tell for sure.
> 
>>
>>
>> Detail: reading cpu.stat already waits on the ongoing flusher by always
>> taking the lock (as it use lock to protect other things).  This
>> indirectly created what you are asking for... If your userspace program
>> first reads cpu.stat, then it will serve as a barrier that waits for the
>> ongoing flusher.
> 
> 
> Making userspace programs read cpu.stat before memory.stat to get the
> correct flushing behavior is certainly not the way to address this
> imo.
> 
>>
>>
>> Could we have a sysctl that enabled "accurate" cgroup rstat reading?
>> As most users don't need this high accuracy.
> 
> 
> I did a lot of testing of flushing latency in the commit I referred to
> above, you'll find numbers there. I think the problem for you mainly
> comes from having 12 kswapd threads flushing the root, they compete
> among one another as well as with userspace reads. Shakeel's patch
> should address this, and honestly I think the longer-term approach
> should be to eliminate all in-kernel flushers [2], rather than making
> all flushers inaccurate.
> 

I like the idea of eliminate all in-kernel flushers.
Until someone works on that I will use my patch in production as I need
to fix the production issues ASAP.

> [2]https://lore.kernel.org/lkml/CAJD7tkaBfWWS32VYAwkgyfzkD_WbUUbx+rrK-Cc6OT7UN27DYA@mail.gmail.com/
> 
>>
>>
>>
>>>>
>>>> When multiple (12) kswapd's are running, then waiting for ongoing
>>>> flusher will cause us to delay all other kswapd threads, for on my
>>>> production system approx 24 ms (see attached prod graph).
>>>> Matt (Cc) is currently[1] looking into page alloc failures that are
>>>> happening across the fleet, when NIC RX packets as those allocs are
>>>> GFP_ATOMIC.  So, basically kswapd isn't reclaiming memory fast enough on
>>>> our systems, which could be related to this flush latency.  (Quick calc,
>>>> prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are
>>>> handled, that exceed RX ring size 1024).
>>>>
>>>>     [1]
>>>> https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/
>>>>
>>>> For this reason, I don't want to have code that waits for ongoing
>>>> flushers to finish.  This is why I changed the code.
>>>
>>> My understanding was that the previous versions solved most of the
>>> problem. However, if it's not enough and we need to completely skip
>>> the flush, then I don't think this patch is the right way to go. This
>>> affects all flushers, not just the reclaim path, and not even just the
>>> memcg flushers. Waiting for ongoing flushers was a generic approach
>>> that should work for all flushers, but completely skipping the flush
>>> is not.
>>>
>>
>> IMHO waiting for ongoing flushers was not a good idea, as it caused
>> other issues. Letting 11 other kswapd wait 24 ms for a single kswapd
>> thread was not good for our production systems.
> 
> 
> If it takes one kswapd thread 24 ms to flush the stats, then that's
> the raw flush time. If all 12 kswapd threads started at different
> times they would all spend 24 ms flushing anyway, so waiting for the
> ongoing flusher is not a regression or a newly introduced delay. The
> ongoing flusher mechanism rather tries to optimize this by avoiding
> the lock contention and waiting for the ongoing flusher rather than
> competing on the lock and redoing some of the work.
>

We are observing kswapd isn't running "fast-enough" in production (e.g.
when packet process using GFP_ATOMIC alloc are starting to fail).  Thus,
I really don't want to delay 11 other kswapd threads, by waiting on a
flush, I really prefer to skip the flush, such that they can do the much
needed memory reclaim work.

>>
>>
>> I need remind people that "completely skipping the flush" due to ongoing
>> flusher have worked well for us before kernel v6.8 (before commit
>> 7d7ef0a4686a). So, I really don't see skipping the flush, when there is
>> an ongoing flusher is that controversial.
> 
> 
> Skipping the flush was introduced in v5.15 as part of aa48e47e3906
> ("memcg: infrastructure to flush memcg stats"). Before then, reading
> the stats from userspace was as accurate as possible. When we moved to
> a kernel with that commit we noticed the regression. So it wasn't
> always the case that userspace reads were inaccurate or did not flush.
> 
>>
>>
>> I think it is controversial to *wait* for the ongoing flusher as that
>> IMHO defeats the whole purpose of having an ongoing flusher...
> 
> 
> The point of having an ongoing flusher is to avoid reacquiring the
> lock after they are done, and checking all the percpu trees again for
> updates, which would be a waste of work and unnecessary contention on
> the lock. It's definitely an improvement over directly competing over
> the lock, yet it doesn't sacrifice accuracy.
> 
>>
>> then we could just have a normal mutex lock if we want to wait.
> 
> 
> I am not against using a mutex as I mentioned before. If there are
> concerns about priority inversions we can add a timeout as we
> discussed. The ongoing flusher mechanism is similar in principle to a
> mutex, the advantage is that whoever holds the lock does not sleep, so
> it gets the flush done faster and waiters wake up faster.
> 

My plan is to lower contention on this rstat lock "enough" (e.g. with
this patch), which should make it safer to switch to a mutex.

>>
>>
>>> If your problem is specifically the flush in the reclaim path, then
>>> Shakeel's patch to replace that flush with the ratelimited version
>>> should fix your problem. It was already merged into mm-stable (so
>>> headed toward v6.11 AFAICT).
>>>
>>>>
>>>>
>>>>> You also never addressed my concern here about 'ongoing' while we are
>>>>> accessing it, and never responded to my question in v8 about expanding
>>>>> this to support non-root cgroups once we shift to a mutex.
>>>>>
>>>>
>>>> I don't think we should expand this to non-root cgroups.  My production
>>>> data from this V10 shows we don't need this for non-root cgroups.
>>>
>>> Right, because you are concerned with the flush in the kswapd path
>>> specifically. This patch touches affects much more than that.
>>>
>>
>> It is not only the flush in the kswapd path that concerns me.
>> My other concern is userspace cadvisor that periodically reads ALL the
>> .stat files on the system and creates flush spikes (every minute).  When
>> advisor collides with root-cgroup flush (either 2 sec periodic or
>> kswapd) then bad interactions happens in prod.
> 
> 
> I believe the problem here is the kswapd flushers competing with
> cadvisor userspace read. I don't think the periodic flusher that runs
> every 2s colliding with the cadvisor reader that runs every minute
> would really cause a problem. Also both of these paths should not be
> latency sensitive anyway. So again, Shakeel's patch should help here.
> 
> Did you check if Shakeel's patch fixes your problem?
> 

I will also try out Shakeel's patch. This will hide the specific
contention issue until something starves the kthread that does the
periodic 2 second flush (for 2 periods). In production we are seeing
kthreads getting starved longer than 20 seconds.  This often happens in
connection with OOM killer. This recreates the kswapd lock contention
situation at a very unfortunate point in time.  Thus, it makes sense to
have this ongoing flusher lock contention protection in place.

BTW, there is still a mem_cgroup_flush_stats() remaining in
zswap_shrinker_count(), that we might still hit, after Shakeel's patch.
And a direct call to do_flush_stats() in obj_cgroup_may_zswap().

>>
>>
>>>>
>>>>
>>>>> I don't appreciate the silent yet drastic change made in this version
>>>>> and without addressing concerns raised in previous versions. Please
>>>>> let me know if I missed something.
>>>>>
>>>>
>>>> IMHO we needed a drastic change, because patch was getting too
>>>> complicated, and my production experiments showed that it was no-longer
>>>> solving the contention issue (due to allowing non-root cgroups to become
>>>> ongoing).
>>>
>>> I thought we agreed to wait for the ongoing flusher to complete, but
>>> only allow root cgroups to become the ongoing flusher (at least
>>> initially). Not sure what changed.
>>>
>>
>> Practical implementation (with completions) and production experiments
>> is what changed my mind. Thus, I no-longer agree that waiting for the
>> ongoing flusher to complete is the right solution.
> 
> 
> My understanding based on [1] was that the ongoing flusher mechanism
> with only root flushers fixed the problem, but maybe you got more data
> afterward.
> 

[1] is V8 (that allowed ongoing flusher below level 2) which production
experience from that shows that we need to confine ongoing flusher to
being the root cgroup only.  (This already worked in V2).  The V9
production experience shows that using 'completions' caused issues and
implementing this race free is very hard.


> [1] https://lore.kernel.org/lkml/ee0f7d29-1385-4799-ab4b-6080ca7fd74b@kernel.org/
> 
>>
>>
>>
>>>>
>>>> Production servers with this V10 patch applied shows HUGE improvements.
>>>> Let me grab a graf showing level-0 contention events being reduced from
>>>> 1360 event/sec to 0.277 events/sec.  I had to change to a log-scale graf
>>>> to make improvement visible.  The wait-time is also basically gone.  The
>>>> improvements are so convincing and highly needed, that we are going to
>>>> deploy this improvement.  I usually have a very strong upstream first
>>>> principle, but we simply cannot wait any-longer for a solution to this
>>>> production issue.
>>>
>>> Of course there is a huge improvement, you are completely skipping the
>>> flush :) You are gaining a lot of performance but you'll also lose
>>> something, there is no free lunch here. This may be an acceptable
>>> tradeoff for the reclaim path, but definitely not for all flushers.
>>>
>>
>> To move forward, can you please list the flushers that cannot accept
>> this trade off?
>> Then I can exclude these in the next version.
> 
> 
> I am not sure which flushers would be problematic, I have seen
> problems with the memcg userspace readers, but this doesn't mean it's
> the only source of problems. There is also a flush in the zswap path
> for charging that may be affected, but we discussed moving that to a
> completely different approach to avoid the flush.
> 
> I am against skipping the flush for all cases with exceptions. What
> Shakeel did was the opposite and the less controversial approach, skip
> the flush only for the reclaim path because it's the one we observed
> causing problems.
> 

I've coded a V11 that reduce the places we skip-the-flush on contention,
and wait-for-flush in all the userspace reader cases.

--Jesper
Yosry Ahmed Sept. 12, 2024, 4:34 p.m. UTC | #9
>
> [..]
> >>
> >> My userspace readers (of /sys/fs/cgroup/*/*/memory.stat) are primarily
> >> cadvisor and systemd, which doesn't need this accuracy.
> >>
> >> Can you explain your userspace use-case that need this accuracy?
> >
> >
> > Please look at the commit log of this patch [1] that removed
> > stats_flush_ongoing (the one in Fixes).
> >
> > [1]https://lore.kernel.org/lkml/20231129032154.3710765-6-yosryahmed@google.com/
> >
>
> I think I understand the inaccuracy concern now.  So, it is the 2 second
> periodic flush that is the concern.  That can cause up-to 2 seconds old
> data to be read by userspace, when read contend with ongoing root
> flusher (if it doesn't wait for the flush).  I agree, that 2 sec old
> data is too inaccurate.

Yeah and it's not just the delay, it's also the fact that you may read
the stats *after* an event (e.g. proactive reclaim or memory usage
spike), and get the stats from *before* the event. This leads to wrong
decisions being made by userspace.

>
>
> I'm coding V11 that will "wait_for_flush" in the userspace call paths.

I'd rather we keep the flushers consistent to avoid complexity if
possible (i.e. if Shakeel's patch works for you). But if that's the
only way going forward maybe that's what we need for now.. I will wait
to see the code.

[..]
>
>
> I like the idea of eliminate all in-kernel flushers.
> Until someone works on that I will use my patch in production as I need
> to fix the production issues ASAP.

I took a brief look at the ones in the reclaim path and I don't think
they are easy to remove tbh. Maybe MGLRU will become the default soon
and they naturally go away (MGLRU does not have these flushes).

[..]
>
> >
> > If it takes one kswapd thread 24 ms to flush the stats, then that's
> > the raw flush time. If all 12 kswapd threads started at different
> > times they would all spend 24 ms flushing anyway, so waiting for the
> > ongoing flusher is not a regression or a newly introduced delay. The
> > ongoing flusher mechanism rather tries to optimize this by avoiding
> > the lock contention and waiting for the ongoing flusher rather than
> > competing on the lock and redoing some of the work.
> >
>
> We are observing kswapd isn't running "fast-enough" in production (e.g.
> when packet process using GFP_ATOMIC alloc are starting to fail).  Thus,
> I really don't want to delay 11 other kswapd threads, by waiting on a
> flush, I really prefer to skip the flush, such that they can do the much
> needed memory reclaim work.

That's one more reason I think maybe this needs to be handled in the
reclaim path. I do not think other flushers relate to this situation.
It would be nice if we can just skip the flush in the reclaim path
under these circumstances.

>
> >>
> >>
> >> I need remind people that "completely skipping the flush" due to ongoing
> >> flusher have worked well for us before kernel v6.8 (before commit
> >> 7d7ef0a4686a). So, I really don't see skipping the flush, when there is
> >> an ongoing flusher is that controversial.
> >
> >
> > Skipping the flush was introduced in v5.15 as part of aa48e47e3906
> > ("memcg: infrastructure to flush memcg stats"). Before then, reading
> > the stats from userspace was as accurate as possible. When we moved to
> > a kernel with that commit we noticed the regression. So it wasn't
> > always the case that userspace reads were inaccurate or did not flush.
> >>
> >> I think it is controversial to *wait* for the ongoing flusher as that
> >> IMHO defeats the whole purpose of having an ongoing flusher...
> >
> >
> > The point of having an ongoing flusher is to avoid reacquiring the
> > lock after they are done, and checking all the percpu trees again for
> > updates, which would be a waste of work and unnecessary contention on
> > the lock. It's definitely an improvement over directly competing over
> > the lock, yet it doesn't sacrifice accuracy.
> >
> >>
> >> then we could just have a normal mutex lock if we want to wait.
> >
> >
> > I am not against using a mutex as I mentioned before. If there are
> > concerns about priority inversions we can add a timeout as we
> > discussed. The ongoing flusher mechanism is similar in principle to a
> > mutex, the advantage is that whoever holds the lock does not sleep, so
> > it gets the flush done faster and waiters wake up faster.
> >
>
> My plan is to lower contention on this rstat lock "enough" (e.g. with
> this patch), which should make it safer to switch to a mutex.

Do we know that switching to a mutex in the current state is
problematic? If the only concern is priority inversion then a timeout
should work.

Also, I don't think a mutex will help your case of kswapd not running
fast enough, right?

[..]
>
>
> >>
> >> It is not only the flush in the kswapd path that concerns me.
> >> My other concern is userspace cadvisor that periodically reads ALL the
> >> .stat files on the system and creates flush spikes (every minute).  When
> >> advisor collides with root-cgroup flush (either 2 sec periodic or
> >> kswapd) then bad interactions happens in prod.
> >
> >
> > I believe the problem here is the kswapd flushers competing with
> > cadvisor userspace read. I don't think the periodic flusher that runs
> > every 2s colliding with the cadvisor reader that runs every minute
> > would really cause a problem. Also both of these paths should not be
> > latency sensitive anyway. So again, Shakeel's patch should help here.
> >
> > Did you check if Shakeel's patch fixes your problem?
> >
>
> I will also try out Shakeel's patch. This will hide the specific
> contention issue until something starves the kthread that does the
> periodic 2 second flush (for 2 periods). In production we are seeing
> kthreads getting starved longer than 20 seconds.  This often happens in
> connection with OOM killer. This recreates the kswapd lock contention
> situation at a very unfortunate point in time.  Thus, it makes sense to
> have this ongoing flusher lock contention protection in place.

Yeah we may need to completely skip the flush under dire circumstances
in the reclaim path, as I mentioned above. This feels more like a
reclaim problem than an rstat problem at this point.

>
>
> BTW, there is still a mem_cgroup_flush_stats() remaining in
> zswap_shrinker_count(), that we might still hit, after Shakeel's patch.
> And a direct call to do_flush_stats() in obj_cgroup_may_zswap().

Yeah there is a plan to remove these.

Nhat, are you currently working on this? If not I can try to find a
few cycles to address this.

[..]
>
> >>>
> >>> I thought we agreed to wait for the ongoing flusher to complete, but
> >>> only allow root cgroups to become the ongoing flusher (at least
> >>> initially). Not sure what changed.
> >>>
> >>
> >> Practical implementation (with completions) and production experiments
> >> is what changed my mind. Thus, I no-longer agree that waiting for the
> >> ongoing flusher to complete is the right solution.
> >
> >
> > My understanding based on [1] was that the ongoing flusher mechanism
> > with only root flushers fixed the problem, but maybe you got more data
> > afterward.
> >
>
> [1] is V8 (that allowed ongoing flusher below level 2) which production
> experience from that shows that we need to confine ongoing flusher to
> being the root cgroup only.  (This already worked in V2).  The V9
> production experience shows that using 'completions' caused issues and
> implementing this race free is very hard.


So you observed production problems with completions even when only
root cgroups are allowed to be the ongoing flusher, after you thought
it fixed the problem initially. Did I get that right?
Nhat Pham Sept. 12, 2024, 6:24 p.m. UTC | #10
On Thu, Sep 12, 2024 at 10:28 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> >
> > I'm not, but Joshua from my team is working on it :)
>
> Great, thanks for letting me know!

FWIW, I think the zswap_shrinker_count() path is fairly trivial to
take care of :)  We only need the stats itself, and you don't even
need any tree traversal tbh - technically it is most accurate to track
zswap memory usage of the memcg itself - one atomic counter per
zswap_lruvec_struct should suffice.

obj_cgroup_may_zswap() could be more troublesome - we need the entire
subtree data to make the decision, at each level :) How about this:

1. Add a per-memcg counter to track zswap memory usage.

2. At obj_cgroup_may_zswap() time, the logic is unchanged - we
traverse the tree from current memcg to root memcg, grabbing the
memcg's counter and check for usage.

3. At obj_cgroup_charge_zswap() time, we have to perform another
upward traversal again, to increment the counters. Would this be too
expensive?

We still need the whole obj_cgroup charging spiel, for memory usage
purposes, but this should allow us to remove the MEMCG_ZSWAP_B.
Similarly, another set of counters can be introduced to remove
MEMCG_ZSWAPPED...

Yosry, Joshua, how do you feel about this design? Step 3 is the part
where I'm least certain about, but it's the only way I can think of
that would avoid any flushing action. You have to pay the price of
stat updates at *some* point :)
Yosry Ahmed Sept. 12, 2024, 6:50 p.m. UTC | #11
On Thu, Sep 12, 2024 at 11:25 AM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Thu, Sep 12, 2024 at 10:28 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > >
> > > I'm not, but Joshua from my team is working on it :)
> >
> > Great, thanks for letting me know!
>
> FWIW, I think the zswap_shrinker_count() path is fairly trivial to
> take care of :)  We only need the stats itself, and you don't even
> need any tree traversal tbh - technically it is most accurate to track
> zswap memory usage of the memcg itself - one atomic counter per
> zswap_lruvec_struct should suffice.

Do you mean per-lruvec or per-memcg?

>
> obj_cgroup_may_zswap() could be more troublesome - we need the entire
> subtree data to make the decision, at each level :) How about this:
>
> 1. Add a per-memcg counter to track zswap memory usage.
>
> 2. At obj_cgroup_may_zswap() time, the logic is unchanged - we
> traverse the tree from current memcg to root memcg, grabbing the
> memcg's counter and check for usage.
>
> 3. At obj_cgroup_charge_zswap() time, we have to perform another
> upward traversal again, to increment the counters. Would this be too
> expensive?
>
> We still need the whole obj_cgroup charging spiel, for memory usage
> purposes, but this should allow us to remove the MEMCG_ZSWAP_B.
> Similarly, another set of counters can be introduced to remove
> MEMCG_ZSWAPPED...
>
> Yosry, Joshua, how do you feel about this design? Step 3 is the part
> where I'm least certain about, but it's the only way I can think of
> that would avoid any flushing action. You have to pay the price of
> stat updates at *some* point :)

In (2) obj_cgroup_may_zswap, the upward flush should get cheaper
because we avoid the stats flush, we just read an atomic counter
instead.

In (3) obj_cgroup_charge_zswap(), we will do an upward traversal and
atomic update. In a lot of cases this can be cheaper than the flush we
avoid, but we'd need to measure it with different hierarchies to be
sure. Keep in mind that if we consume_obj_stock() is not successful
and we fallback to obj_cgroup_charge_pages(), and we already do an
upward traversal. So it may be just fine to do the upward traversal.

So I think the plan sounds good. We just need some perf testing to
make sure (3) does not introduce regressions.
diff mbox series

Patch

diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 37e6cc91d576..e12061fc3832 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1200,7 +1200,7 @@  static int blkcg_print_stat(struct seq_file *sf, void *v)
 	if (!seq_css(sf)->parent)
 		blkcg_fill_root_iostats();
 	else
-		cgroup_rstat_flush(blkcg->css.cgroup);
+		cgroup_rstat_flush_relaxed(blkcg->css.cgroup);
 
 	rcu_read_lock();
 	hlist_for_each_entry_rcu(blkg, &blkcg->blkg_list, blkcg_node) {
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 2150ca60394b..4f11b5721500 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -691,6 +691,7 @@  void cgroup_rstat_updated(struct cgroup *cgrp, int cpu);
 void cgroup_rstat_flush(struct cgroup *cgrp);
 void cgroup_rstat_flush_hold(struct cgroup *cgrp);
 void cgroup_rstat_flush_release(struct cgroup *cgrp);
+void cgroup_rstat_flush_relaxed(struct cgroup *cgrp);
 
 /*
  * Basic resource stats.
diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
index a06b45272411..91559ba3b187 100644
--- a/kernel/cgroup/rstat.c
+++ b/kernel/cgroup/rstat.c
@@ -11,6 +11,8 @@ 
 
 static DEFINE_SPINLOCK(cgroup_rstat_lock);
 static DEFINE_PER_CPU(raw_spinlock_t, cgroup_rstat_cpu_lock);
+static struct cgroup *cgrp_rstat_ongoing_flusher = NULL;
+static struct task_struct *cgrp_rstat_ongoing_flusher_ID = NULL;
 
 static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
 
@@ -299,6 +301,67 @@  static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
 	spin_unlock_irq(&cgroup_rstat_lock);
 }
 
+static inline bool cgroup_is_root(struct cgroup *cgrp)
+{
+	return cgroup_parent(cgrp) == NULL;
+}
+
+/**
+ * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher
+ * @cgrp: target cgroup
+ *
+ * Function return value follow trylock semantics. Returning true when lock is
+ * obtained. Returning false when not locked and it detected flushing can be
+ * skipped as another ongoing flusher is taking care of the flush.
+ *
+ * For callers that depend on flush completing before returning a strict option
+ * is provided.
+ */
+static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict)
+{
+	struct cgroup *ongoing;
+
+	if (strict)
+		goto lock;
+
+	/*
+	 * Check if ongoing flusher is already taking care of this.  Descendant
+	 * check is necessary due to cgroup v1 supporting multiple root's.
+	 */
+	ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
+	if (ongoing && cgroup_is_descendant(cgrp, ongoing))
+		return false;
+
+	/* Grab right to be ongoing flusher */
+	if (!ongoing && cgroup_is_root(cgrp)) {
+		struct cgroup *old;
+
+		old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp);
+		if (old) {
+			/* Lost race for being ongoing flusher */
+			if (cgroup_is_descendant(cgrp, old))
+				return false;
+		}
+		/* Due to lock yield combined with strict mode record ID */
+		WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current);
+	}
+lock:
+	__cgroup_rstat_lock(cgrp, -1);
+
+	return true;
+}
+
+static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp)
+{
+	if (cgrp == READ_ONCE(cgrp_rstat_ongoing_flusher) &&
+	    READ_ONCE(cgrp_rstat_ongoing_flusher_ID) == current) {
+		WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, NULL);
+		WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL);
+	}
+
+	__cgroup_rstat_unlock(cgrp, -1);
+}
+
 /* see cgroup_rstat_flush() */
 static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
 	__releases(&cgroup_rstat_lock) __acquires(&cgroup_rstat_lock)
@@ -333,6 +396,17 @@  static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
 	}
 }
 
+static void __cgroup_rstat_flush(struct cgroup *cgrp, bool strict)
+{
+	might_sleep();
+
+	if (!cgroup_rstat_trylock_flusher(cgrp, strict))
+		return;
+
+	cgroup_rstat_flush_locked(cgrp);
+	cgroup_rstat_unlock_flusher(cgrp);
+}
+
 /**
  * cgroup_rstat_flush - flush stats in @cgrp's subtree
  * @cgrp: target cgroup
@@ -348,11 +422,12 @@  static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
  */
 __bpf_kfunc void cgroup_rstat_flush(struct cgroup *cgrp)
 {
-	might_sleep();
+	__cgroup_rstat_flush(cgrp, true);
+}
 
-	__cgroup_rstat_lock(cgrp, -1);
-	cgroup_rstat_flush_locked(cgrp);
-	__cgroup_rstat_unlock(cgrp, -1);
+void cgroup_rstat_flush_relaxed(struct cgroup *cgrp)
+{
+	__cgroup_rstat_flush(cgrp, false);
 }
 
 /**
@@ -368,8 +443,11 @@  void cgroup_rstat_flush_hold(struct cgroup *cgrp)
 	__acquires(&cgroup_rstat_lock)
 {
 	might_sleep();
-	__cgroup_rstat_lock(cgrp, -1);
-	cgroup_rstat_flush_locked(cgrp);
+
+	if (cgroup_rstat_trylock_flusher(cgrp, false))
+		cgroup_rstat_flush_locked(cgrp);
+	else
+		__cgroup_rstat_lock(cgrp, -1);
 }
 
 /**
@@ -379,7 +457,7 @@  void cgroup_rstat_flush_hold(struct cgroup *cgrp)
 void cgroup_rstat_flush_release(struct cgroup *cgrp)
 	__releases(&cgroup_rstat_lock)
 {
-	__cgroup_rstat_unlock(cgrp, -1);
+	cgroup_rstat_unlock_flusher(cgrp);
 }
 
 int cgroup_rstat_init(struct cgroup *cgrp)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 71fe2a95b8bd..be2022f27b5f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -876,7 +876,7 @@  static void do_flush_stats(struct mem_cgroup *memcg)
 	if (mem_cgroup_is_root(memcg))
 		WRITE_ONCE(flush_last_time, jiffies_64);
 
-	cgroup_rstat_flush(memcg->css.cgroup);
+	cgroup_rstat_flush_relaxed(memcg->css.cgroup);
 }
 
 /*