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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Mel Gorman <mgorman@techsingularity.net>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        "Darrick J. Wong" <djwong@kernel.org>,
        Dave Chinner <dchinner@redhat.com>, Jan Kara <jack@suse.cz>,
        Vlastimil Babka <vbabka@suse.cz>,
        Jesper Dangaard Brouer <brouer@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux-XFS <linux-xfs@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/page_alloc: Always attempt to allocate at least one
 page during bulk allocation
Thread-Topic: [PATCH] mm/page_alloc: Always attempt to allocate at least one
 page during bulk allocation
Thread-Index: AQHYcOC43NoaGkYC5U+9BlY8CFI0/a0y3deA
Date:   Fri, 27 May 2022 15:38:24 +0000
Message-ID: <964C1F37-11E3-4C28-B4DB-817E9A6F7DF7@oracle.com>
References: <20220526091210.GC3441@techsingularity.net>
In-Reply-To: <20220526091210.GC3441@techsingularity.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?OhUlSyYH5RQx8H88YcU0XNV6QN07yO435u3Gxnj0TJJIsWshToDjPD/WnZSh?=
 =?us-ascii?Q?GOkbGZWeQTHouT+EfHEVMB1JJ12uz2hqnAT1hZrE8A8hjTTrJeGb9GtVS02J?=
 =?us-ascii?Q?0A/n/Qsr8jMa2c7jhx/eX/gTIr5/QYcjznWWrv6/wAlH1jQqUTsAN9DJ5afV?=
 =?us-ascii?Q?L4wG2H214JZdeYq2hyxx9rOwsulxq61DD571ycZscJy8B5pspQ3PWJgXkVWy?=
 =?us-ascii?Q?E4Pes5hUVJWEUiJuw2OHpGI+7oeoENwN+mGXTnBVvFcaP5zHbVy8gVIgP9eL?=
 =?us-ascii?Q?cm1NCRqeJLVYcfnR+Uvex4qHRpVLgodtkIXEsbM87J9ETg+0C/DKpeNIoV/4?=
 =?us-ascii?Q?n8g5KLZVBinBj5igSjbAwuLaXnpAGr4RqwCOaSXMyYj8tpoHQcRnPZSvkfQY?=
 =?us-ascii?Q?PM57xA3WfIfN+pMOUe3kauHobUurOFjtFILTKZJe2sL5k6UahpWW9Iob5/8O?=
 =?us-ascii?Q?bVY2Wq3RsDtEPuikmPaWztp9OpSmEaj2KjRzoyj+yV/90Y0R4/yzQjypLtma?=
 =?us-ascii?Q?SQaOnyNXynZwTAf4SecOU20b4hHq1EuTBf++fpchyy20AlMjRkNmnMZzrBqE?=
 =?us-ascii?Q?OtZGO1RXEfe+8z8pPQz2bf0dyL7M4HPhITjlbrYLHkJ84sJd5jZKNJFRd2j3?=
 =?us-ascii?Q?88TNuW8q0apMCRNN3m24xp9tXTUPFeHHgWwpmjSjn77/fiMaktqMenJmbQqH?=
 =?us-ascii?Q?g9AazXsJnFhAKWPJTvUjMzE0EBTEprvlSoV/L3XlQC0V42d+tpQD5gxRpWct?=
 =?us-ascii?Q?bTJuOaoN/mA4/YWj3fB9wXlUWPaUfRKPbg8DZ7WLinrdp10sg1nW+SQNO9ky?=
 =?us-ascii?Q?vPA9h+mBfrTdHpg8z/+Wr5Ab6rKS2t3fT8rHh03sDyx5o25mji7O+eC5durC?=
 =?us-ascii?Q?asjhQBagNnQOwMkgl4/aPQEec3ADIwUKPDnVhRpO5o2te1sgpZHq/8Vccr7C?=
 =?us-ascii?Q?2bGLYL4RkuepauYDoKxl78jMk3FcqHK4B3SlM+TtolDNbHW+s1SCW54zqOZs?=
 =?us-ascii?Q?7243FeYx1hP4s+tn/R5UBDrwxeIIRRJ+V/+9Xz/edIQzO3WLeBldgBP+i0NC?=
 =?us-ascii?Q?znz0S3z2zrlO8sPrb6wqQnVIInySVhu8pY2mLp1oXHfrGyCcdR/OdjYn2Bji?=
 =?us-ascii?Q?6K/Znq7WHN+muV+AKaM/A9/+dizYd/ykZZLsxBc/pFeySTsaq13/eA+vBhEB?=
 =?us-ascii?Q?XePMFBZb0wB5i4+WvYuEHVltzNmaGmksC8FXYdd5SVEsels3/Mwm2++WujBp?=
 =?us-ascii?Q?xbgxqf/OFGdsCJZJ1ej/bPKWYdk++9WgxM503u5ZDwI8nBuqt2uiUxj+HK+r?=
 =?us-ascii?Q?r90P8/Bh8wVX9BP7EpbnMnJHs9z5oedsRvOLguBc2cez1a1IYYkho4w2695O?=
 =?us-ascii?Q?MLL5BYKtoQl4sBTQlXjoSywIetZzit0ZgDMSpv5BjH6AGNKuhMXz8xbL9LTT?=
 =?us-ascii?Q?MwOnlBXPA/EUVwoQId1xZop4a2Q9XexsyD6jgXAiBmuueywGFOXE0ovsTGP+?=
 =?us-ascii?Q?1rmu5j7qzQyq7SlklaKf6+jplHzOMG1tWIFBw86aXsH052hPZV9N6+1igLDn?=
 =?us-ascii?Q?TbpvtA6/SMS8ES3oVbggszk1w5SM1LbX8vIqXLMe4aYlgBTQvSrL7bYJgelh?=
 =?us-ascii?Q?eejl3cV6SmJ832lGXJQ1orDmjF79jgpAV59qdH6i/alDKFWkf3bXMCR7plzB?=
 =?us-ascii?Q?oNGAUqbo9g3FFqL/X6duEsPpglzt3mAKgSnTgJLWIaz6D7X+sn6aud4sAuDa?=
 =?us-ascii?Q?7smx7gtus7gGrTUmcZxXBsPJ2lZIy2Y=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E230F73EA8A4340B51AC220BA45E316@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59f6ac8c-55b5-4043-72aa-08da3ff6efc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2022 15:38:24.3495
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XMp59hXF3BYmezMMCzEg6j+IUF7L0JVef3npUzuM+iqzNZYcUQ0jdNIwheMy5m+yCzzSqPKAXUR257F9NW5yTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4828
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-27_04:2022-05-27,2022-05-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 adultscore=0 spamscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2205270075
X-Proofpoint-GUID: GIAbxOqIidiXYoJaavRi7t-AQMX33m1p
X-Proofpoint-ORIG-GUID: GIAbxOqIidiXYoJaavRi7t-AQMX33m1p
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,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=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On May 26, 2022, at 5:12 AM, Mel Gorman <mgorman@techsingularity.net> wro=
te:
>=20
> Peter Pavlisko reported the following problem on kernel bugzilla 216007.
>=20
> 	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).
>=20
> 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 o=
n
> users of the API. Adjust the semantics to attempt at least one allocation
> via __alloc_pages() before returning so kswapd is woken if necessary.
>=20
> 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.
>=20
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=3D216007
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=3D215975
> Fixes: 387ba26fb1cb ("mm/page_alloc: add a bulk page allocator")
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> Cc: <stable@vger.kernel.org> # v5.13+

Fwiw, Reviewed-by: Chuck Lever <chuck.lever@oracle.com>


> ---
> mm/page_alloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0e42038382c1..5ced6cb260ed 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5324,8 +5324,8 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int pre=
ferred_nid,
> 		page =3D __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;
> 		}

--
Chuck Lever