On Wed, Mar 10, 2021 at 1:41 PM Yang Shi <shy828...@gmail.com> wrote: > > On Wed, Mar 10, 2021 at 1:08 PM Shakeel Butt <shake...@google.com> wrote: > > > > On Wed, Mar 10, 2021 at 10:54 AM Yang Shi <shy828...@gmail.com> wrote: > > > > > > On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt <shake...@google.com> wrote: > > > > > > > > On Wed, Mar 10, 2021 at 9:46 AM Yang Shi <shy828...@gmail.com> wrote: > > > > > > > > > > The number of deferred objects might get windup to an absurd number, > > > > > and it > > > > > results in clamp of slab objects. It is undesirable for sustaining > > > > > workingset. > > > > > > > > > > So shrink deferred objects proportional to priority and cap > > > > > nr_deferred to twice > > > > > of cache items. > > > > > > > > > > The idea is borrowed from Dave Chinner's patch: > > > > > https://lore.kernel.org/linux-xfs/20191031234618.15403-13-da...@fromorbit.com/ > > > > > > > > > > Tested with kernel build and vfs metadata heavy workload in our > > > > > production > > > > > environment, no regression is spotted so far. > > > > > > > > Did you run both of these workloads in the same cgroup or separate > > > > cgroups? > > > > > > Both are covered. > > > > > > > Have you tried just this patch i.e. without the first 12 patches? > > No. It could be applied without the first 12 patches, but I didn't > test this combination specifically since I don't think it would have > any difference from with the first 12 patches. I tested running the > test case under root memcg, it seems equal to w/o the first 12 patches > and the only difference is where to get nr_deferred.
I am trying to measure the impact of this patch independently. One point I can think of is the global reclaim. The first 12 patches do not aim to improve the global reclaim but this patch will. I am just wondering what would be negative if any of this patch.
