On Wed, Jan 17, 2024 at 02:00:55PM -0500, Jeff Layton wrote: > I'm really not a fan of tunables or different kconfig options, > especially for something niche like this. > > I also question whether this accounting will show up under any real- > world workloads, and whether it was just wrong to revert those patches > back in 2021. > > File locking is an activity where we inherently expect to block. Ideally > we don't if the lock is uncontended of course, but it's always a > possibility. > > The benchmark that prompted the regression basically just tries to > create and release a bunch of file locks as quickly as possible. > Legitimate applications that do a lot of very rapid locking like this > benchmark are basically non-existent. Usually the pattern is: > > acquire lock > do some (relatively slow) I/O > release lock > > In that sort of scenario, is this memcg accounting more than just line > noise? I wonder whether we should just bite the bullet and see whether > there are any real workloads that suffer due to SLAB_ACCOUNT being > enabled on these caches? That's a good point. If the microbenchmark isn't likely to be even remotely realistic, maybe we should just revert the revert until if/when somebody shows a real world impact. Linus, any objections to that? -- Josh