[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201704062002.FAE18212.OJOFOHLStFVFQM@I-love.SAKURA.ne.jp>
Date: Thu, 6 Apr 2017 20:02:24 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
mhocko@...nel.org, hannes@...xchg.org, mgorman@...hsingularity.net,
david@...morbit.com, apolyakov@...et.ru, lists@...singer.com,
hughd@...gle.com
Subject: Re: [PATCH v8] mm: Add memory allocation watchdog kernel thread.
Andrew, anything else I can do?
Tetsuo Handa wrote:
> Regarding maintenance burden, I consider this patch is least invasive
> because it does not make __GFP_NOWARN flag's semantic confusing while
> providing administrators some hints [4]. Also, this patch will remain
> useful because we might overlook something that can cause infinite
> loop (or significant delay) in future changes, and we can remove this
> patch when we achieve safe and robust memory management subsystem.
>
> Changes from v7 [11]:
>
> (1) Reflect review comments from Andrew Morton. (Convert "u8 type" to
> "bool report", use CPUHP_PAGE_ALLOC_DEAD event and replace
> for_each_possible_cpu() with for_each_online_cpu(), reuse existing
> rcu_lock_break() and hung_timeout_jiffies() for now, update comments).
We are still sometimes overlooking unexpected delays like
http://lkml.kernel.org/r/alpine.LSU.2.11.1704051331420.4288@eggly.anvils and
http://lkml.kernel.org/r/da13c3c7-b514-67b0-2eb9-6d6af277901b@wiesinger.com
and I think we will in the future. I believe that this patch is helpful for
catching such cases.
Powered by blists - more mailing lists