All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@suse.com>, <hannes@cmpxchg.org>,
	<vdavydov.dev@gmail.com>, <akpm@linux-foundation.org>,
	<shakeelb@google.com>, <willy@infradead.org>, <alexs@kernel.org>,
	<richard.weiyang@gmail.com>, <songmuchun@bytedance.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	<cgroups@vger.kernel.org>
Subject: Re: [PATCH 2/5] mm, memcg: narrow the scope of percpu_charge_mutex
Date: Mon, 2 Aug 2021 20:40:04 -0700	[thread overview]
Message-ID: <YQi6lOT6j2DtOGlT@carbon.dhcp.thefacebook.com> (raw)
In-Reply-To: <4a3c23c4-054c-2896-29c5-8cf9a4deee98@huawei.com>

On Sat, Jul 31, 2021 at 10:29:52AM +0800, Miaohe Lin wrote:
> On 2021/7/30 14:50, Michal Hocko wrote:
> > On Thu 29-07-21 20:06:45, Roman Gushchin wrote:
> >> On Thu, Jul 29, 2021 at 08:57:52PM +0800, Miaohe Lin wrote:
> >>> Since percpu_charge_mutex is only used inside drain_all_stock(), we can
> >>> narrow the scope of percpu_charge_mutex by moving it here.
> >>>
> >>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> >>> ---
> >>>  mm/memcontrol.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >>> index 6580c2381a3e..a03e24e57cd9 100644
> >>> --- a/mm/memcontrol.c
> >>> +++ b/mm/memcontrol.c
> >>> @@ -2050,7 +2050,6 @@ struct memcg_stock_pcp {
> >>>  #define FLUSHING_CACHED_CHARGE	0
> >>>  };
> >>>  static DEFINE_PER_CPU(struct memcg_stock_pcp, memcg_stock);
> >>> -static DEFINE_MUTEX(percpu_charge_mutex);
> >>>  
> >>>  #ifdef CONFIG_MEMCG_KMEM
> >>>  static void drain_obj_stock(struct obj_stock *stock);
> >>> @@ -2209,6 +2208,7 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> >>>   */
> >>>  static void drain_all_stock(struct mem_cgroup *root_memcg)
> >>>  {
> >>> +	static DEFINE_MUTEX(percpu_charge_mutex);
> >>>  	int cpu, curcpu;
> >>
> >> It's considered a good practice to protect data instead of code paths. After
> >> the proposed change it becomes obvious that the opposite is done here: the mutex
> >> is used to prevent a simultaneous execution of the code of the drain_all_stock()
> >> function.
> > 
> > The purpose of the lock was indeed to orchestrate callers more than any
> > data structure consistency.
> >  
> >> Actually we don't need a mutex here: nobody ever sleeps on it. So I'd replace
> >> it with a simple atomic variable or even a single bitfield. Then the change will
> >> be better justified, IMO.
> > 
> > Yes, mutex can be replaced by an atomic in a follow up patch.
> > 
> 
> Thanks for both of you. It's a really good suggestion. What do you mean is something like below?
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 616d1a72ece3..508a96e80980 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2208,11 +2208,11 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
>   */
>  static void drain_all_stock(struct mem_cgroup *root_memcg)
>  {
> -       static DEFINE_MUTEX(percpu_charge_mutex);
>         int cpu, curcpu;
> +       static atomic_t drain_all_stocks = ATOMIC_INIT(-1);
> 
>         /* If someone's already draining, avoid adding running more workers. */
> -       if (!mutex_trylock(&percpu_charge_mutex))
> +       if (!atomic_inc_not_zero(&drain_all_stocks))
>                 return;

It should work, but why not a simple atomic_cmpxchg(&drain_all_stocks, 0, 1) and
initialize it to 0? Maybe it's just my preference, but IMO (0, 1) is easier
to understand than (-1, 0) here. Not a strong opinion though, up to you.

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
To: Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>,
	hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
	vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	alexs-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/5] mm, memcg: narrow the scope of percpu_charge_mutex
Date: Mon, 2 Aug 2021 20:40:04 -0700	[thread overview]
Message-ID: <YQi6lOT6j2DtOGlT@carbon.dhcp.thefacebook.com> (raw)
In-Reply-To: <4a3c23c4-054c-2896-29c5-8cf9a4deee98-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

On Sat, Jul 31, 2021 at 10:29:52AM +0800, Miaohe Lin wrote:
> On 2021/7/30 14:50, Michal Hocko wrote:
> > On Thu 29-07-21 20:06:45, Roman Gushchin wrote:
> >> On Thu, Jul 29, 2021 at 08:57:52PM +0800, Miaohe Lin wrote:
> >>> Since percpu_charge_mutex is only used inside drain_all_stock(), we can
> >>> narrow the scope of percpu_charge_mutex by moving it here.
> >>>
> >>> Signed-off-by: Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>> ---
> >>>  mm/memcontrol.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >>> index 6580c2381a3e..a03e24e57cd9 100644
> >>> --- a/mm/memcontrol.c
> >>> +++ b/mm/memcontrol.c
> >>> @@ -2050,7 +2050,6 @@ struct memcg_stock_pcp {
> >>>  #define FLUSHING_CACHED_CHARGE	0
> >>>  };
> >>>  static DEFINE_PER_CPU(struct memcg_stock_pcp, memcg_stock);
> >>> -static DEFINE_MUTEX(percpu_charge_mutex);
> >>>  
> >>>  #ifdef CONFIG_MEMCG_KMEM
> >>>  static void drain_obj_stock(struct obj_stock *stock);
> >>> @@ -2209,6 +2208,7 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> >>>   */
> >>>  static void drain_all_stock(struct mem_cgroup *root_memcg)
> >>>  {
> >>> +	static DEFINE_MUTEX(percpu_charge_mutex);
> >>>  	int cpu, curcpu;
> >>
> >> It's considered a good practice to protect data instead of code paths. After
> >> the proposed change it becomes obvious that the opposite is done here: the mutex
> >> is used to prevent a simultaneous execution of the code of the drain_all_stock()
> >> function.
> > 
> > The purpose of the lock was indeed to orchestrate callers more than any
> > data structure consistency.
> >  
> >> Actually we don't need a mutex here: nobody ever sleeps on it. So I'd replace
> >> it with a simple atomic variable or even a single bitfield. Then the change will
> >> be better justified, IMO.
> > 
> > Yes, mutex can be replaced by an atomic in a follow up patch.
> > 
> 
> Thanks for both of you. It's a really good suggestion. What do you mean is something like below?
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 616d1a72ece3..508a96e80980 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2208,11 +2208,11 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
>   */
>  static void drain_all_stock(struct mem_cgroup *root_memcg)
>  {
> -       static DEFINE_MUTEX(percpu_charge_mutex);
>         int cpu, curcpu;
> +       static atomic_t drain_all_stocks = ATOMIC_INIT(-1);
> 
>         /* If someone's already draining, avoid adding running more workers. */
> -       if (!mutex_trylock(&percpu_charge_mutex))
> +       if (!atomic_inc_not_zero(&drain_all_stocks))
>                 return;

It should work, but why not a simple atomic_cmpxchg(&drain_all_stocks, 0, 1) and
initialize it to 0? Maybe it's just my preference, but IMO (0, 1) is easier
to understand than (-1, 0) here. Not a strong opinion though, up to you.

Thanks!

  parent reply	other threads:[~2021-08-03  3:40 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 12:57 [PATCH 0/5] Cleanups and fixup for memcontrol Miaohe Lin
2021-07-29 12:57 ` Miaohe Lin
2021-07-29 12:57 ` [PATCH 1/5] mm, memcg: remove unused functions Miaohe Lin
2021-07-29 12:57   ` Miaohe Lin
2021-07-29 14:07   ` Shakeel Butt
2021-07-29 14:07     ` Shakeel Butt
2021-07-29 14:07     ` Shakeel Butt
2021-07-30  2:39   ` Muchun Song
2021-07-30  2:39     ` Muchun Song
2021-07-30  2:39     ` Muchun Song
2021-07-30  2:57   ` Roman Gushchin
2021-07-30  2:57     ` Roman Gushchin
2021-07-30  6:45   ` Michal Hocko
2021-07-30  6:45     ` Michal Hocko
2021-07-29 12:57 ` [PATCH 2/5] mm, memcg: narrow the scope of percpu_charge_mutex Miaohe Lin
2021-07-29 12:57   ` Miaohe Lin
2021-07-30  2:42   ` Muchun Song
2021-07-30  2:42     ` Muchun Song
2021-07-30  2:42     ` Muchun Song
2021-07-30  3:06   ` Roman Gushchin
2021-07-30  3:06     ` Roman Gushchin
2021-07-30  6:50     ` Michal Hocko
2021-07-30  6:50       ` Michal Hocko
2021-07-31  2:29       ` Miaohe Lin
2021-07-31  2:29         ` Miaohe Lin
2021-08-02  6:49         ` Michal Hocko
2021-08-02  6:49           ` Michal Hocko
2021-08-02  9:54           ` Miaohe Lin
2021-08-02  9:54             ` Miaohe Lin
2021-08-03  3:40         ` Roman Gushchin [this message]
2021-08-03  3:40           ` Roman Gushchin
2021-08-03  6:29           ` Miaohe Lin
2021-08-03  6:29             ` Miaohe Lin
2021-08-03  7:11             ` Michal Hocko
2021-08-03  7:11               ` Michal Hocko
2021-08-03  7:13               ` Roman Gushchin
2021-08-03  7:13                 ` Roman Gushchin
2021-08-03  7:27                 ` Michal Hocko
2021-08-03  7:27                   ` Michal Hocko
2021-08-03  9:33             ` Muchun Song
2021-08-03  9:33               ` Muchun Song
2021-08-03  9:33               ` Muchun Song
2021-08-03 10:50               ` Miaohe Lin
2021-08-03 10:50                 ` Miaohe Lin
2021-08-03 14:15       ` Johannes Weiner
2021-08-03 14:15         ` Johannes Weiner
2021-08-04  8:20         ` Michal Hocko
2021-08-04  8:20           ` Michal Hocko
2021-08-05  1:44           ` Miaohe Lin
2021-08-05  1:44             ` Miaohe Lin
2021-07-30  6:46   ` Michal Hocko
2021-07-29 12:57 ` [PATCH 3/5] mm, memcg: save some atomic ops when flush is already true Miaohe Lin
2021-07-29 12:57   ` Miaohe Lin
2021-07-29 14:40   ` Shakeel Butt
2021-07-29 14:40     ` Shakeel Butt
2021-07-29 14:40     ` Shakeel Butt
2021-07-30  2:37   ` Muchun Song
2021-07-30  2:37     ` Muchun Song
2021-07-30  2:37     ` Muchun Song
2021-07-30  3:07   ` Roman Gushchin
2021-07-30  3:07     ` Roman Gushchin
2021-07-30  6:51   ` Michal Hocko
2021-07-30  6:51     ` Michal Hocko
2021-07-29 12:57 ` [PATCH 4/5] mm, memcg: avoid possible NULL pointer dereferencing in mem_cgroup_init() Miaohe Lin
2021-07-29 12:57   ` Miaohe Lin
2021-07-29 13:52   ` Matthew Wilcox
2021-07-29 13:52     ` Matthew Wilcox
2021-07-30  1:50     ` Miaohe Lin
2021-07-30  1:50       ` Miaohe Lin
2021-07-30  3:12   ` Roman Gushchin
2021-07-30  3:12     ` Roman Gushchin
2021-07-30  6:29     ` Miaohe Lin
2021-07-30  6:29       ` Miaohe Lin
2021-07-30  6:44     ` Michal Hocko
2021-07-30  6:44       ` Michal Hocko
2021-07-31  2:05       ` Miaohe Lin
2021-07-31  2:05         ` Miaohe Lin
2021-08-02  6:43         ` Michal Hocko
2021-08-02  6:43           ` Michal Hocko
2021-08-02 10:00           ` Miaohe Lin
2021-08-02 10:00             ` Miaohe Lin
2021-08-02 10:42             ` Michal Hocko
2021-08-02 10:42               ` Michal Hocko
2021-08-02 11:18               ` Miaohe Lin
2021-08-02 11:18                 ` Miaohe Lin
2021-07-29 12:57 ` [PATCH 5/5] mm, memcg: always call __mod_node_page_state() with preempt disabled Miaohe Lin
2021-07-29 12:57   ` Miaohe Lin
2021-07-29 14:39   ` Shakeel Butt
2021-07-29 14:39     ` Shakeel Butt
2021-07-29 14:39     ` Shakeel Butt
2021-07-30  1:52     ` Miaohe Lin
2021-07-30  1:52       ` Miaohe Lin
2021-07-30  2:33       ` [External] " Muchun Song
2021-07-30  2:33         ` Muchun Song
2021-07-30  2:33         ` Muchun Song
2021-07-30  2:46         ` Miaohe Lin
2021-07-30  2:46           ` Miaohe Lin

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=YQi6lOT6j2DtOGlT@carbon.dhcp.thefacebook.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexs@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richard.weiyang@gmail.com \
    --cc=shakeelb@google.com \
    --cc=songmuchun@bytedance.com \
    --cc=vdavydov.dev@gmail.com \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.