All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm: avoid blocking lock_page() in kcompactd
Date: Fri, 10 Jan 2020 09:22:56 +0000	[thread overview]
Message-ID: <20200110092256.GN3466@techsingularity.net> (raw)
In-Reply-To: <20200109225646.22983-1-xiyou.wangcong@gmail.com>

On Thu, Jan 09, 2020 at 02:56:46PM -0800, Cong Wang wrote:
> We observed kcompactd hung at __lock_page():
> 
>  INFO: task kcompactd0:57 blocked for more than 120 seconds.
>        Not tainted 4.19.56.x86_64 #1
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  kcompactd0      D    0    57      2 0x80000000
>  Call Trace:
>   ? __schedule+0x236/0x860
>   schedule+0x28/0x80
>   io_schedule+0x12/0x40
>   __lock_page+0xf9/0x120
>   ? page_cache_tree_insert+0xb0/0xb0
>   ? update_pageblock_skip+0xb0/0xb0
>   migrate_pages+0x88c/0xb90
>   ? isolate_freepages_block+0x3b0/0x3b0
>   compact_zone+0x5f1/0x870
>   kcompactd_do_work+0x130/0x2c0
>   ? __switch_to_asm+0x35/0x70
>   ? __switch_to_asm+0x41/0x70
>   ? kcompactd_do_work+0x2c0/0x2c0
>   ? kcompactd+0x73/0x180
>   kcompactd+0x73/0x180
>   ? finish_wait+0x80/0x80
>   kthread+0x113/0x130
>   ? kthread_create_worker_on_cpu+0x50/0x50
>   ret_from_fork+0x35/0x40
> 
> which faddr2line maps to:
> 
>   migrate_pages+0x88c/0xb90:
>   lock_page at include/linux/pagemap.h:483
>   (inlined by) __unmap_and_move at mm/migrate.c:1024
>   (inlined by) unmap_and_move at mm/migrate.c:1189
>   (inlined by) migrate_pages at mm/migrate.c:1419
> 
> Sometimes kcompactd eventually got out of this situation, sometimes not.
> 
> I think for memory compaction, it is a best effort to migrate the pages,
> so it doesn't have to wait for I/O to complete. It is fine to call
> trylock_page() here, which is pretty much similar to
> buffer_migrate_lock_buffers().
> 
> Given MIGRATE_SYNC_LIGHT is used on compaction path, just relax the
> check for it.
> 

Is this a single page being locked for a long time or multiple pages
being locked without reaching a reschedule point?

If it's a single page being locked, it's important to identify what held
page lock for 2 minutes because that is potentially a missing
unlock_page. The kernel in question is old -- 4.19.56. Are there any
other modifications to that kernel?

-- 
Mel Gorman
SUSE Labs


  parent reply	other threads:[~2020-01-10  9:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 22:56 [PATCH] mm: avoid blocking lock_page() in kcompactd Cong Wang
2020-01-10  0:28 ` Yang Shi
2020-01-10  1:01   ` Cong Wang
2020-01-10  4:51     ` Cong Wang
2020-01-10  7:38 ` Michal Hocko
2020-01-20 22:48   ` Cong Wang
2020-01-21  9:00     ` Michal Hocko
2020-01-26 19:53       ` Cong Wang
2020-01-26 23:39         ` Matthew Wilcox
2020-01-27 15:00           ` Michal Hocko
2020-01-27 19:06             ` Matthew Wilcox
2020-01-28  1:25               ` Yang Shi
2020-01-28  6:03                 ` Matthew Wilcox
2020-01-28  8:17               ` Michal Hocko
2020-01-28  8:30                 ` Matthew Wilcox
2020-01-28  9:13                   ` Michal Hocko
2020-01-28 10:48                     ` Matthew Wilcox
2020-01-28 11:39                       ` Michal Hocko
2020-01-28 19:44                         ` Cong Wang
2020-01-30 22:52                           ` Cong Wang
2020-02-13  7:48                         ` Michal Hocko
2020-02-13 16:46                           ` Matthew Wilcox
2020-02-13 17:08                             ` Michal Hocko
2020-02-14  4:27                               ` Matthew Wilcox
2020-02-14  6:55                                 ` Michal Hocko
2020-01-27 14:49         ` Michal Hocko
2020-01-28  0:46           ` Cong Wang
2020-01-28  8:22             ` Michal Hocko
2020-01-10  9:22 ` Mel Gorman [this message]
2020-01-20 22:41   ` Cong Wang
2020-01-21 19:21     ` Yang Shi
2020-01-21  8:26   ` Hillf Danton
2020-01-21  9:06     ` 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=20200110092256.GN3466@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=xiyou.wangcong@gmail.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 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.