Re: [PATCH v7 2/3] btrfs: always uses root memcgroup for filemap_add_folio()

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

 





在 2024/7/22 17:04, Michal Hocko 写道:
On Sat 20-07-24 07:41:19, Qu Wenruo wrote:
[...]
So according to the trend, I'm pretty sure VFS people will reject such
new interface just to skip accounting.

I would just give it a try with your usecase described. If this is a
nogo then the root cgroup workaround is still available.

I have submitted a patchset doing exactly that, and thankfully that's the series where I got all the helpful feedbacks:

https://lore.kernel.org/linux-btrfs/92dea37a395781ee4d5cf8b16307801ccd8a5700.1720572937.git.wqu@xxxxxxxx/

Unfortunately I haven't get any feedback from the VFS guys.


Thus the GFP_NO_ACCOUNT solution looks more feasible.

So we have GFP_ACCOUNT to opt in for accounting and now we should be
adding GFP_NO_ACCOUNT to override it? This doesn't sound like a good use
of gfp flags (which we do not have infinitely) and it is also quite
confusing TBH.

The problem is, for filemap_add_folio(), we didn't specify GFP_ACCOUNT (nor any other caller) but it is still doing the charge, due to the mostly-correct assumption that all filemap page caches are accessible to user space programs.

So one can argue that, cgroup is still charged even if no GFP_ACCOUNT is specified.

But I get your point, indeed it's not that a good idea to introduce GFP_NO_ACCOUNT.

Thanks,
Qu




[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