linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <kernel@kyup.com>
To: linux-mm@kvack.org
Cc: mgorman@suse.de, Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.cz>, Marian Marinov <mm@1h.com>,
	SiteGround Operations <operations@siteground.com>
Subject: Making per-cpu lists draining dependant on a flag
Date: Fri, 9 Oct 2015 14:00:31 +0300	[thread overview]
Message-ID: <56179E4F.5010507@kyup.com> (raw)

Hello mm people,


I want to ask you the following question which stemmed from analysing
and chasing this particular deadlock:
http://permalink.gmane.org/gmane.linux.kernel/2056730

To summarise it:

For simplicity I will use the following nomenclature:
t1 - kworker/u96:0
t2 - kworker/u98:39
t3 - kworker/u98:7

t1 issues drain_all_pages which generates IPI's, at the same time
however, t2 has already started doing async write of pages
as part of its normal operation but is blocked upon t1 completion of
its IPI (generated from drain_all_pages) since they both work on the
same dm-thin volume. At the same time again, t3 is executing
ext4_finish_bio, which disables interrupts, yet is dependent on t2
completing its writes.  But since it has disabled interrupts, it wont
respond to t1's IPI and at this point a hard lock up occurs. This
happens, since drain_all_pages calls on_each_cpu_mask with the last
argument equal to  "true" meaning "wait until the ipi handler has
finished", which of course will never happen in the described situation.

Based on that I was wondering whether avoiding such situation might
merit making drain_all_pages invocation from
__alloc_pages_direct_reclaim dependent on a particular GFP being passed
e.g. GFP_NOPCPDRAIN or something along those lines?

Alternatively would it be possible to make the IPI asycnrhonous e.g.
calling on_each_cpu_mask with the last argument equal to false?

Regards,
Nikolay

--
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:[~2015-10-09 11:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 11:00 Nikolay Borisov [this message]
2015-10-13 14:43 ` Making per-cpu lists draining dependant on a flag Michal Hocko
2015-10-13 14:55   ` Nikolay Borisov
2015-10-14  8:37 ` Michal Hocko
2015-10-14  9:06   ` Nikolay Borisov

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=56179E4F.5010507@kyup.com \
    --to=kernel@kyup.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=mm@1h.com \
    --cc=operations@siteground.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;
as well as URLs for NNTP newsgroup(s).