From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B089C77B7A for ; Thu, 25 May 2023 08:29:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CAB26B0074; Thu, 25 May 2023 04:29:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77B426B0075; Thu, 25 May 2023 04:29:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66992900002; Thu, 25 May 2023 04:29:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5506E6B0074 for ; Thu, 25 May 2023 04:29:38 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 26D6D1C7896 for ; Thu, 25 May 2023 08:29:38 +0000 (UTC) X-FDA: 80828103636.16.727AA44 Received: from outbound-smtp01.blacknight.com (outbound-smtp01.blacknight.com [81.17.249.7]) by imf08.hostedemail.com (Postfix) with ESMTP id 492AD160021 for ; Thu, 25 May 2023 08:29:34 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.7 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685003375; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YTAvkqImRk9wQeR1IwOhHPnGQ2iwkLvyWgZCSUh9UOw=; b=PUX2XYJepnRhDd4Cc7c2hPEyjGyF7fXNIRkmw00V9vFglVZVyBoYJJj3Ceq4ARAa5OROlT vLyEsuZRQSHWXfM2JhvZFHzmi5IqYEPley87euX7i/cD7e3WPFnQjxOTQmqQS+vt5Ybsph 66nnPmdhI0YCNASLtwLWpk7kYJZKVOo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.7 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685003375; a=rsa-sha256; cv=none; b=FUh91uelkyIcuyg3WB9GuAhSfJkwZkq3eN06Cg1bwee1NhdiT3qILUMGYNyfaHQcnipCg4 mFlDOFch4QbLgDmEajrc5V/TOihODhMn+pH4QNBCIrRl7kPtV3JrAwgVGBBbfgHpSvLVYX 5o4nHR2JF3sFFOcBz1Dfctwp7P0+xM4= Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp01.blacknight.com (Postfix) with ESMTPS id 64A9EC4AE0 for ; Thu, 25 May 2023 09:29:33 +0100 (IST) Received: (qmail 13895 invoked from network); 25 May 2023 08:29:33 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 May 2023 08:29:33 -0000 Date: Thu, 25 May 2023 09:29:28 +0100 From: Mel Gorman To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm: compaction: avoid GFP_NOFS ABBA deadlock Message-ID: <20230525082928.ovuz77znv763jx3e@techsingularity.net> References: <20230519111359.40475-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230519111359.40475-1-hannes@cmpxchg.org> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 492AD160021 X-Stat-Signature: 3oy8yfsfxo6yh38kz1mtg19nmoxc35sm X-HE-Tag: 1685003374-832465 X-HE-Meta: U2FsdGVkX190oFnVXPh1IW27rRrsfUQnZkepJE8eoqVAwA4Xt1RDSgxF6ZEsPYXwV+5HIYHZ1tQLABz4kSaHzMQiGfcR8Sd2zgbEKZUZheTIKnEPzZD9Cnv2GLRR/870dIaW8Eb+7FrfzqSX/MW/fNBDeMnKC+5mQ0EleJ0M0Tiqcwp1qyFjI1XYKyrkolD5u/n5efCIF7eKcXh5JF7+GotCVWhnTOCduFKV37KNlpUWuyUmptOVWH6yDouHDuybzNVoQhq4cRgXP+K1MWfTwaAKEFfGZHtwy2wzUr5zZoyM+89etJlaJKxUVeuBx/NdH2xM8FgAL76s/mBsYsH9+RTBxOwKd0QBHLOMCVi14yzqtpTqUYgBgqW62f026TezmPfbVTcA3vUmwaJV+/Ef76ZZTZ+w+tPDZrYLuiBvGDi3L8m1QWs1YLxJZ1NQOdgUaINJ63FYbDzLN0yuVIW05kcq4BTcmyASUQkKdz3NMM3Cn8vSTbQN9uZXOh+jMpFRLXpDJVxtaFF9HGoVA/dUyqki1Kq/Kr+H0N4WibxV5CeP5GtM+o3ijtIbzcGbC4n6RCTgQzBTxNSqR31aiY7wcGZosMZuRjCRsiG8AqrjqJAq2SshcM0rYZc8S2RAvy64lHje31GDlmudUPcE68nYu9VUSCPtXI+fgulrzLfSET22hoH+SXHW2SNnVvicqJ7CHvSm++ZKZU3faTl04Z4BqfzVxxj/zGBGf9HoBs9FbOCSghEN4ixR3n1jCPzXduU8LT8R8BnXiDcn4OHKta6RsaXwD9ENF3ZcJq/Ms4j9unHRa4SJEFyD+EU1mJcZ6ZypN1IC0B6xzou/BVSorKW0wWtSrflQjft83AhRL3LiS82W4j/cfc/c1VQtfRgWMfLABApQSX/cNiexhT/cjCzWZ5pXtG+FTkjnvTE4gxPC37zv6WOjZjFB0JEJmquXUsxMuw3OMekSwbkZ5+JSevw 2e9DxIZL SjNJDzmRxOPqxfoEB6KXnyp0GQQoE/Wkh8zIzNdnOwXSlw9ZOgXmRGY3xok9zzmQzZAW3Wxt8W0vOsmLRPiGNDqtSt/Mz0s7rvdZB0xxL4NkGZep1vLnY0Bo9aJz9S3ebqnb+0zXbL4vfEvfIPDOA9PYKjEgVrmewUjm0YFORZ4bDTUf+DXq+vEugHywLmmCu5F10suHq3rqyc+Uk389goj+6jkIwG1X8HepQ26AlHTD2QQhidhT/Ym9vLZPDaHRFGU7tCPY0wP5VnRuMlx6DBK32jCmauogneR8aF0G/Y0Z/hyG07PoSjQ6qgU2hkAsL8lwouAhdW7JYWd4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 19, 2023 at 01:13:59PM +0200, Johannes Weiner wrote: > During stress testing with higher-order allocations, a deadlock > scenario was observed in compaction: One GFP_NOFS allocation was > sleeping on mm/compaction.c::too_many_isolated(), while all CPUs in > the system were busy with compactors spinning on buffer locks held by > the sleeping GFP_NOFS allocation. > > Reclaim is susceptible to this same deadlock; we fixed it by granting > GFP_NOFS allocations additional LRU isolation headroom, to ensure it > makes forward progress while holding fs locks that other reclaimers > might acquire. Do the same here. > > This code has been like this since compaction was initially merged, > and I only managed to trigger this with out-of-tree patches that > dramatically increase the contexts that do GFP_NOFS compaction. While > the issue is real, it seems theoretical in nature given existing > allocation sites. Worth fixing now, but no Fixes tag or stable CC. > > Signed-off-by: Johannes Weiner Acked-by: Mel Gorman > --- > mm/compaction.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > v2: > - clarify too_many_isolated() comment (Mel) > - split isolation deadlock from no-contiguous-anon lockups as that's > a different scenario and deserves its own patch > > diff --git a/mm/compaction.c b/mm/compaction.c > index c8bcdea15f5f..c9a4b6dffcf2 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -745,8 +745,9 @@ isolate_freepages_range(struct compact_control *cc, > } > > /* Similar to reclaim, but different enough that they don't share logic */ > -static bool too_many_isolated(pg_data_t *pgdat) > +static bool too_many_isolated(struct compact_control *cc) > { > + pg_data_t *pgdat = cc->zone->zone_pgdat; > bool too_many; > > unsigned long active, inactive, isolated; > @@ -758,6 +759,17 @@ static bool too_many_isolated(pg_data_t *pgdat) > isolated = node_page_state(pgdat, NR_ISOLATED_FILE) + > node_page_state(pgdat, NR_ISOLATED_ANON); > > + /* > + * Allow GFP_NOFS to isolate past the limit set for regular > + * compaction runs. This prevents an ABBA deadlock when other > + * compactors have already isolated to the limit, but are > + * blocked on filesystem locks held by the GFP_NOFS thread. > + */ > + if (cc->gfp_mask & __GFP_FS) { > + inactive >>= 3; > + active >>= 3; > + } > + > too_many = isolated > (inactive + active) / 2; > if (!too_many) > wake_throttle_isolated(pgdat); > @@ -806,7 +818,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn, > * list by either parallel reclaimers or compaction. If there are, > * delay for some time until fewer pages are isolated > */ > - while (unlikely(too_many_isolated(pgdat))) { > + while (unlikely(too_many_isolated(cc))) { > /* stop isolation if there are still pages not migrated */ > if (cc->nr_migratepages) > return -EAGAIN; > -- > 2.40.0 > -- Mel Gorman SUSE Labs