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

[Qu Wenruo <wqu@suse.com>]

在 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