Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2198473iof; Tue, 7 Jun 2022 22:58:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiJtKVUTfuNPkLL16bI5IIxufH0AvQbQTEqVPzaIXMUywxmjA9QjW1v4c8X0+d+ktcqvr4 X-Received: by 2002:a63:104a:0:b0:3fa:d1ea:54d7 with SMTP id 10-20020a63104a000000b003fad1ea54d7mr28771880pgq.124.1654667925438; Tue, 07 Jun 2022 22:58:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654667925; cv=none; d=google.com; s=arc-20160816; b=DbxB2TgVrTHcbr5JJXaHkalQfU8MTdulXG3hTjYfbEMbP0eefBdZxF8HcXuRV0dj09 ZUob8UBMhoDKU5X40cNkfPU5GCBPO+G1k1hBBbhlLqd7EkG0WHIPLrOKccVmqI/5m1/o yxlXupfzV/ieBD9CyFY8DODHwx0z44u0jr4ns5r7I6w8xe4Qb5LcP7hZt0AiMnEsL9qG kCshXd07O87ZQkSNYNvkgw6K71NFmzQSbFD1ReBSt0/aYSxlc8hjyX9PK4pn0OECWhMj MrwbLW562HOhg3TS7gzPuMmUwUXpnHpfbgZ3gJ/nCrJav4B5oHoh5jj+dtZBr/T69Zn8 tKSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=vUxJN6/IWP4uE1rIOS30rh5BYr0e/NOEb1iT2hPBZ1w=; b=mnPUIkLJxPFWU3OVLI+eixX4dNjq1hmC5cAnssoMyxm+EKm6cQUt9LeHizeefxnrl8 J1UKCtmeg8lyMQNgUNRniAoHBd+CrylBaiFihnIjsDmxOhH0uYE1DkbSFejJPElx3xWQ WO8QXqfi9hzOMzVqIVa04NX+hlwzsiaIMV8ehRb9BPGrEozdO2tnMFH25mkdTsUZ5/to 2kuW2LBSqPs7KAs/722nMDfGwWShZmmOMju+R7vwUkkoXIE2CfVRxFYQOVRzsWap/2GX mqiJKoan0vE+B/vySfvBxM2YLtEQCVnVAigT/tWFaTsRWcDSNfnQlboJECW+m0tUXKrR QNeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="ySKyICo/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id s17-20020a170902ea1100b001616377802csi31607195plg.88.2022.06.07.22.58.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 22:58:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="ySKyICo/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3D9F62F5AA8; Tue, 7 Jun 2022 22:27:05 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233532AbiFHBUF (ORCPT + 99 others); Tue, 7 Jun 2022 21:20:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1382057AbiFGW3A (ORCPT ); Tue, 7 Jun 2022 18:29:00 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35C84274B5F; Tue, 7 Jun 2022 12:23:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 613D860B14; Tue, 7 Jun 2022 19:23:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72BADC385A2; Tue, 7 Jun 2022 19:23:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629824; bh=cJcaACk93XZiwSdeQhL4bIIlasHe+pa17GOztwySCbM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ySKyICo/Kt3rxDR/7q/6u4r5NbisQRSwmANpuQrr26jdkzemLDG9qt/Nb/AOgfeWB imZrjGieUBCWyCEMVj9euQYhSLLhQcPYFAvCnrqaXUY5TSSc9Q5JQpvUWzrQ2kWiUe QnjUTnAdwpnBqh/xZ6ONVsOMGp6A0DHA0ksINfmA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mel Gorman , "Darrick J. Wong" , Dave Chinner , Jan Kara , Vlastimil Babka , Jesper Dangaard Brouer , Chuck Lever , Andrew Morton Subject: [PATCH 5.18 830/879] mm/page_alloc: always attempt to allocate at least one page during bulk allocation Date: Tue, 7 Jun 2022 19:05:48 +0200 Message-Id: <20220607165026.946543643@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mel Gorman commit c572e4888ad1be123c1516ec577ad30a700bbec4 upstream. Peter Pavlisko reported the following problem on kernel bugzilla 216007. When I try to extract an uncompressed tar archive (2.6 milion files, 760.3 GiB in size) on newly created (empty) XFS file system, after first low tens of gigabytes extracted the process hangs in iowait indefinitely. One CPU core is 100% occupied with iowait, the other CPU core is idle (on 2-core Intel Celeron G1610T). It was bisected to c9fa563072e1 ("xfs: use alloc_pages_bulk_array() for buffers") but XFS is only the messenger. The problem is that nothing is waking kswapd to reclaim some pages at a time the PCP lists cannot be refilled until some reclaim happens. The bulk allocator checks that there are some pages in the array and the original intent was that a bulk allocator did not necessarily need all the requested pages and it was best to return as quickly as possible. This was fine for the first user of the API but both NFS and XFS require the requested number of pages be available before making progress. Both could be adjusted to call the page allocator directly if a bulk allocation fails but it puts a burden on users of the API. Adjust the semantics to attempt at least one allocation via __alloc_pages() before returning so kswapd is woken if necessary. It was reported via bugzilla that the patch addressed the problem and that the tar extraction completed successfully. This may also address bug 215975 but has yet to be confirmed. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215975 Link: https://lkml.kernel.org/r/20220526091210.GC3441@techsingularity.net Fixes: 387ba26fb1cb ("mm/page_alloc: add a bulk page allocator") Signed-off-by: Mel Gorman Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: Jan Kara Cc: Vlastimil Babka Cc: Jesper Dangaard Brouer Cc: Chuck Lever Cc: [5.13+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5324,8 +5324,8 @@ unsigned long __alloc_pages_bulk(gfp_t g page = __rmqueue_pcplist(zone, 0, ac.migratetype, alloc_flags, pcp, pcp_list); if (unlikely(!page)) { - /* Try and get at least one page */ - if (!nr_populated) + /* Try and allocate at least one page */ + if (!nr_account) goto failed_irq; break; }