LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim
Date: Thu, 15 Mar 2018 19:06:25 +0300 [thread overview]
Message-ID: <782fbe3a-4025-16f7-bfae-424e1bc6f073@virtuozzo.com> (raw)
In-Reply-To: <20180315155316.GY4865@magnolia>
On 15.03.2018 18:53, Darrick J. Wong wrote:
> On Thu, Mar 15, 2018 at 06:01:34PM +0300, Kirill Tkhai wrote:
>> xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg.
>> So, it's called for memcg reclaim too, e.g. this list is shrinked
>> disproportionality to another lists.
>>
>> This looks confusing, so I'm reporting about this.
>> Consider this patch as RFC.
>
> So... I think the reasoning here is that xfs doesn't allocate inodes on
> behalf of any particular memcg (or put another way the cost of the
> inodes is shared by everything in the system) so if the shrinkers get
> called because a particular memcg is bumping up against its limits it
> makes no sense to try to purge xfs inodes?
Yes, since shrinking xfs cached objects doesn't free memcg kmem.
> Followup questions: does the same reasoning apply to the xfs buffer and
> quota shrinkers?
It's not need, as these shrinker don't have SHRINKER_MEMCG_AWARE flag.
So, they are called only in case of global reclaim (memcg == NULL).
But they may require another type of change. They use list_lru,
so they may need to have SHRINKER_MEMCG_AWARE flag. This is depends
on how objects linked to xfs_buftarg::bt_lru and xfs_quotainfo::qi_lru
are allocated. If they are accounted to memcg (i.e., use GFP_ACCOUNT
flag in their kmalloc/slab alloc/etc), they have to have this flag.
Ideally, all user initiated allocations should be made with this flag.
If they already use GFP_ACCOUNT while shrinker is not marked as SHRINKER_MEMCG_AWARE,
it never shrinks objects related to memcgs.
> Do any filesystems associate their metadata memory
> allocations with a specific memcg? If not, why not put this in
> super_cache_{scan,count}?
They do, since generic super_cache_{scan,count} have a deal with sb's s_dentry_lru
and s_inode_lru, and use list lru, which supports memcg accounting.
> --D
>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>> fs/xfs/xfs_super.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
>> index 951271f57d00..124568aefa94 100644
>> --- a/fs/xfs/xfs_super.c
>> +++ b/fs/xfs/xfs_super.c
>> @@ -1788,6 +1788,8 @@ xfs_fs_nr_cached_objects(
>> struct super_block *sb,
>> struct shrink_control *sc)
>> {
>> + if (sc->memcg)
>> + return 0;
>> return xfs_reclaim_inodes_count(XFS_M(sb));
>> }
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-03-15 16:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 15:01 Kirill Tkhai
2018-03-15 15:53 ` Darrick J. Wong
2018-03-15 16:06 ` Kirill Tkhai [this message]
2018-03-15 17:49 ` Michal Hocko
2018-03-15 19:28 ` Kirill Tkhai
2018-03-15 19:32 ` Michal Hocko
2018-03-15 19:42 ` Kirill Tkhai
2018-03-15 23:03 ` Dave Chinner
2018-03-16 8:55 ` Kirill Tkhai
2018-03-16 21:39 ` Dave Chinner
2018-03-19 11:06 ` Kirill Tkhai
2018-03-19 11:25 ` Kirill Tkhai
2018-03-20 0:18 ` Dave Chinner
2018-03-20 13:15 ` Kirill Tkhai
2018-03-20 14:34 ` Dave Chinner
2018-03-21 16:15 ` Kirill Tkhai
2018-03-22 5:01 ` Dave Chinner
2018-03-22 16:52 ` Kirill Tkhai
2018-03-22 23:46 ` Dave Chinner
2018-03-23 12:39 ` Kirill Tkhai
2018-03-26 2:37 ` Dave Chinner
2018-03-26 11:16 ` Kirill Tkhai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=782fbe3a-4025-16f7-bfae-424e1bc6f073@virtuozzo.com \
--to=ktkhai@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--subject='Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).