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
