Re: [PATCH V7 1/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 19, 2024 at 3:48 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>
> On Fri, Jul 19, 2024 at 09:54:41AM GMT, Jesper Dangaard Brouer wrote:
> >
> >
> > On 19/07/2024 02.40, Shakeel Butt wrote:
> > > Hi Jesper,
> > >
> > > On Wed, Jul 17, 2024 at 06:36:28PM GMT, Jesper Dangaard Brouer wrote:
> > > >
> > > [...]
> > > >
> > > >
> > > > Looking at the production numbers for the time the lock is held for level 0:
> > > >
> > > > @locked_time_level[0]:
> > > > [4M, 8M)     623 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@               |
> > > > [8M, 16M)    860 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> > > > [16M, 32M)   295 |@@@@@@@@@@@@@@@@@                                   |
> > > > [32M, 64M)   275 |@@@@@@@@@@@@@@@@                                    |
> > > >
> > >
> > > Is it possible to get the above histogram for other levels as well?
> >
> > Data from other levels available in [1]:
> >  [1]
> > https://lore.kernel.org/all/8c123882-a5c5-409a-938b-cb5aec9b9ab5@xxxxxxxxxx/
> >
> > IMHO the data shows we will get most out of skipping level-0 root-cgroup
> > flushes.
> >
>
> Thanks a lot of the data. Are all or most of these locked_time_level[0]
> from kswapds? This just motivates me to strongly push the ratelimited
> flush patch of mine (which would be orthogonal to your patch series).

Jesper and I were discussing a better ratelimiting approach, whether
it's measuring the time since the last flush, or only skipping if we
have a lot of flushes in a specific time frame (using __ratelimit()).
I believe this would be better than the current memcg ratelimiting
approach, and we can remove the latter.

WDYT?

>
> Shakeel





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux