All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: drop hotplug lock from lru_add_drain_all
Date: Tue, 14 Nov 2017 15:23:47 +0100	[thread overview]
Message-ID: <20171114142347.syzyd6tlnpe2afur@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1711141512180.2044@nanos>

On Tue 14-11-17 15:13:27, Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > Pulling cpu hotplug locks inside the mm core function like
> > lru_add_drain_all just asks for problems and the recent lockdep splat
> > [1] just proves this. While the usage in that particular case might
> > be wrong we should prevent from locking as lru_add_drain_all is used
> > at many places. It seems that this is not all that hard to achieve
> > actually.
> > 
> > We have done the same thing for drain_all_pages which is analogous by
> > a459eeb7b852 ("mm, page_alloc: do not depend on cpu hotplug locks inside
> > the allocator"). All we have to care about is to handle
> >       - the work item might be executed on a different cpu in worker from
> >         unbound pool so it doesn't run on pinned on the cpu
> > 
> >       - we have to make sure that we do not race with page_alloc_cpu_dead
> >         calling lru_add_drain_cpu
> > 
> > the first part is already handled because the worker calls lru_add_drain
> > which disables preemption when calling lru_add_drain_cpu on the local
> > cpu it is draining. The later is true because page_alloc_cpu_dead
> > is called on the controlling CPU after the hotplugged CPU vanished
> > completely.
> > 
> > [1] http://lkml.kernel.org/r/089e0825eec8955c1f055c83d476@google.com
> > 
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> > ---
> > Hi,
> > this has been posted as 2 patch series [1] previously. It turned out
> > that the first patch was simply broken and the second one could be
> > simplified because the irq disabling is just pointless. There were
> > no other objections so I am resending this patch which should remove
> > quite a large space of potential lockups as lru_add_drain_all is used
> > at many places so removing the hoptlug locking is a good thing in
> > general.
> > 
> > Can we have this merged or there are still some objections?
> 
> No objections. The explanation makes sense, but it might be worth to have a
> comment at lru_add_drain_all() which explains the protection rules.

Do you mean wrt. cpu hotplug? Something like

diff --git a/mm/swap.c b/mm/swap.c
index 8bfdcab9f83e..fe6d645e8536 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -688,6 +688,11 @@ static void lru_add_drain_per_cpu(struct work_struct *dummy)
 
 static DEFINE_PER_CPU(struct work_struct, lru_add_drain_work);
 
+/*
+ * Doesn't need any cpu hotplug locking because we do rely on per-cpu
+ * kworkers being shut down before our page_alloc_cpu_dead callback is
+ * executed on the offlined cpu
+ */
 void lru_add_drain_all(void)
 {
 	static DEFINE_MUTEX(lock);
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: drop hotplug lock from lru_add_drain_all
Date: Tue, 14 Nov 2017 15:23:47 +0100	[thread overview]
Message-ID: <20171114142347.syzyd6tlnpe2afur@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1711141512180.2044@nanos>

On Tue 14-11-17 15:13:27, Thomas Gleixner wrote:
> On Tue, 14 Nov 2017, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > Pulling cpu hotplug locks inside the mm core function like
> > lru_add_drain_all just asks for problems and the recent lockdep splat
> > [1] just proves this. While the usage in that particular case might
> > be wrong we should prevent from locking as lru_add_drain_all is used
> > at many places. It seems that this is not all that hard to achieve
> > actually.
> > 
> > We have done the same thing for drain_all_pages which is analogous by
> > a459eeb7b852 ("mm, page_alloc: do not depend on cpu hotplug locks inside
> > the allocator"). All we have to care about is to handle
> >       - the work item might be executed on a different cpu in worker from
> >         unbound pool so it doesn't run on pinned on the cpu
> > 
> >       - we have to make sure that we do not race with page_alloc_cpu_dead
> >         calling lru_add_drain_cpu
> > 
> > the first part is already handled because the worker calls lru_add_drain
> > which disables preemption when calling lru_add_drain_cpu on the local
> > cpu it is draining. The later is true because page_alloc_cpu_dead
> > is called on the controlling CPU after the hotplugged CPU vanished
> > completely.
> > 
> > [1] http://lkml.kernel.org/r/089e0825eec8955c1f055c83d476@google.com
> > 
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> > ---
> > Hi,
> > this has been posted as 2 patch series [1] previously. It turned out
> > that the first patch was simply broken and the second one could be
> > simplified because the irq disabling is just pointless. There were
> > no other objections so I am resending this patch which should remove
> > quite a large space of potential lockups as lru_add_drain_all is used
> > at many places so removing the hoptlug locking is a good thing in
> > general.
> > 
> > Can we have this merged or there are still some objections?
> 
> No objections. The explanation makes sense, but it might be worth to have a
> comment at lru_add_drain_all() which explains the protection rules.

Do you mean wrt. cpu hotplug? Something like

diff --git a/mm/swap.c b/mm/swap.c
index 8bfdcab9f83e..fe6d645e8536 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -688,6 +688,11 @@ static void lru_add_drain_per_cpu(struct work_struct *dummy)
 
 static DEFINE_PER_CPU(struct work_struct, lru_add_drain_work);
 
+/*
+ * Doesn't need any cpu hotplug locking because we do rely on per-cpu
+ * kworkers being shut down before our page_alloc_cpu_dead callback is
+ * executed on the offlined cpu
+ */
 void lru_add_drain_all(void)
 {
 	static DEFINE_MUTEX(lock);
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-14 14:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-14 13:53 [PATCH] mm: drop hotplug lock from lru_add_drain_all Michal Hocko
2017-11-14 13:53 ` Michal Hocko
2017-11-14 14:13 ` Thomas Gleixner
2017-11-14 14:13   ` Thomas Gleixner
2017-11-14 14:23   ` Michal Hocko [this message]
2017-11-14 14:23     ` Michal Hocko
2017-11-14 14:32     ` Michal Hocko
2017-11-14 14:32       ` Michal Hocko
2017-11-14 15:05       ` Thomas Gleixner
2017-11-14 15:05         ` Thomas Gleixner
2017-11-14 15:11         ` Thomas Gleixner
2017-11-14 15:11           ` Thomas Gleixner
2017-11-14 15:14         ` Michal Hocko
2017-11-14 15:14           ` Michal Hocko
2017-11-16 12:05 Michal Hocko
2017-11-16 12:05 ` Michal Hocko

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=20171114142347.syzyd6tlnpe2afur@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.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.