linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, hannes@cmpxchg.org,
	mhocko@kernel.org, roman.gushchin@linux.dev,
	shakeel.butt@linux.dev, muchun.song@linux.dev,
	akpm@linux-foundation.org, cgroups@vger.kernel.org,
	linux-mm@kvack.org, Michal Hocko <mhocko@suse.com>,
	"Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Subject: Re: [PATCH] btrfs: root memcgroup for metadata filemap_add_folio()
Date: Thu, 3 Oct 2024 17:41:23 +0930	[thread overview]
Message-ID: <b43527db-e763-4e95-8b0c-591afc0e059c@gmx.com> (raw)
In-Reply-To: <Zvz5KfmB8J90TLmO@infradead.org>



在 2024/10/2 17:11, Christoph Hellwig 写道:
> On Tue, Oct 01, 2024 at 07:10:07PM +0930, Qu Wenruo wrote:
>>> This looks pretty ugly.  What speaks against a version of
>>> filemap_add_folio that doesn't charge the memcg?
>>>
>>
>> Because there is so far only one caller has such requirement.
>
> That is a good argument to review the reasons for an interface, but
> not a killer argument.
>
>> Furthermore I believe the folio API doesn't prefer too many different
>> functions doing similar things.
>>
>> E.g. the new folio interfaces only provides filemap_get_folio(),
>> filemap_lock_folio(), and the more generic __filemap_get_folio().
>>
>> Meanwhile there are tons of page based interfaces, find_get_page(),
>> find_or_create_page(), find_lock_page() and flags version etc.
>
> That's a totally different argument, tough.  Those functions were
> trivial wrappers around a more versatile low-level function.
>
> While this is about adding clearly defined functionality, and
> more importantly not exporting totally random low-level data.
>
> What I'd propose is something like the patch below, plus proper
> documentation.  Note that this now does the uncharge on the unlocked
> folio in the error case.  From a quick look that should be fine, but
> someone who actually knows the code needs to confirm that.

The interface looks good to me, especially we completely skip the
charging, which is even better than the current form.

And since Michal is also happy with this idea, I can definite go this path.

Just a little curious, would it be better to introduce a flag for
address_space to indicate whether the folio needs to be charged or not?

Thanks,
Qu
>
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 68a5f1ff3301c6..70da62cf32f6c3 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -1284,6 +1284,8 @@ int add_to_page_cache_lru(struct page *page, struct address_space *mapping,
>   		pgoff_t index, gfp_t gfp);
>   int filemap_add_folio(struct address_space *mapping, struct folio *folio,
>   		pgoff_t index, gfp_t gfp);
> +int filemap_add_folio_nocharge(struct address_space *mapping,
> +		struct folio *folio, pgoff_t index, gfp_t gfp);
>   void filemap_remove_folio(struct folio *folio);
>   void __filemap_remove_folio(struct folio *folio, void *shadow);
>   void replace_page_cache_folio(struct folio *old, struct folio *new);
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 36d22968be9a1e..0a1ae841e8c10f 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -958,20 +958,15 @@ noinline int __filemap_add_folio(struct address_space *mapping,
>   }
>   ALLOW_ERROR_INJECTION(__filemap_add_folio, ERRNO);
>
> -int filemap_add_folio(struct address_space *mapping, struct folio *folio,
> -				pgoff_t index, gfp_t gfp)
> +int filemap_add_folio_nocharge(struct address_space *mapping,
> +		struct folio *folio, pgoff_t index, gfp_t gfp)
>   {
>   	void *shadow = NULL;
>   	int ret;
>
> -	ret = mem_cgroup_charge(folio, NULL, gfp);
> -	if (ret)
> -		return ret;
> -
>   	__folio_set_locked(folio);
>   	ret = __filemap_add_folio(mapping, folio, index, gfp, &shadow);
>   	if (unlikely(ret)) {
> -		mem_cgroup_uncharge(folio);
>   		__folio_clear_locked(folio);
>   	} else {
>   		/*
> @@ -989,6 +984,22 @@ int filemap_add_folio(struct address_space *mapping, struct folio *folio,
>   	}
>   	return ret;
>   }
> +EXPORT_SYMBOL_GPL(filemap_add_folio_nocharge);
> +
> +int filemap_add_folio(struct address_space *mapping, struct folio *folio,
> +		pgoff_t index, gfp_t gfp)
> +{
> +	int ret;
> +
> +	ret = mem_cgroup_charge(folio, NULL, gfp);
> +	if (ret)
> +		return ret;
> +
> +	ret = filemap_add_folio_nocharge(mapping, folio, index, gfp);
> +	if (ret)
> +		mem_cgroup_uncharge(folio);
> +	return ret;
> +}
>   EXPORT_SYMBOL_GPL(filemap_add_folio);
>
>   #ifdef CONFIG_NUMA
>



  parent reply	other threads:[~2024-10-03  8:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28  4:45 Qu Wenruo
2024-09-30 17:23 ` Shakeel Butt
2024-09-30 22:00   ` Qu Wenruo
2024-10-01  1:37     ` Shakeel Butt
2024-10-01  2:03       ` Qu Wenruo
2024-10-01  9:19 ` Christoph Hellwig
2024-10-01  9:40   ` Qu Wenruo
2024-10-02  7:41     ` Christoph Hellwig
2024-10-03  8:07       ` Michal Hocko
2024-10-03 20:39         ` Shakeel Butt
2024-10-03  8:11       ` Qu Wenruo [this message]
2024-10-03  8:22         ` Michal Hocko
2024-10-03  8:23           ` Qu Wenruo
2024-10-03 20:58       ` Johannes Weiner

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=b43527db-e763-4e95-8b0c-591afc0e059c@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=wqu@suse.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox