Re: [PATCH 0/2] mm: skip memcg for certain address space

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

 





在 2024/7/18 16:55, Michal Hocko 写道:
On Thu 18-07-24 09:17:42, Vlastimil Babka (SUSE) wrote:
On 7/18/24 12:38 AM, Qu Wenruo wrote:
[...]
Does the folio order has anything related to the problem or just a
higher order makes it more possible?

I didn't spot anything in the memcg charge path that would depend on the
order directly, hm. Also what kernel version was showing these soft lockups?

Correct. Order just defines the number of charges to be reclaimed.
Unlike the page allocator path we do not have any specific requirements
on the memory to be released.

So I guess the higher folio order just brings more pressure to trigger the problem?


And finally, even without the hang problem, does it make any sense to
skip all the possible memcg charge completely, either to reduce latency
or just to reduce GFP_NOFAIL usage, for those user inaccessible inodes?

Let me just add to the pile of questions. Who does own this memory?

A special inode inside btrfs, we call it btree_inode, which is not accessible out of the btrfs module, and its lifespan is the same as the mounted btrfs filesystem.

The inode is kept inside memory (btrfs_fs_info::btree_inode), it's initialized at the first mount, and released upon the last unmount.

The address_space_operation() are special that it doesn't implement any read/readahead.
Only write/release/invalidate/migrate functions are implemented.

The read are triggered and handled all inside btrfs itself.

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