在 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
