From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6246522AE4E; Tue, 18 Feb 2025 09:16:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.35 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739870167; cv=none; b=TjVib/fdEUuJ8q3fgeY2oog1cZ4bd7muRGaIKLmAsSboe2M9hOxeKI2dui7/kng0H2YSoDZYHKskaRq9hnD8FcuX9Nh0JiYR0X3DX265X/9JvrXwt9ycMF+iU7PcLQ71HTfMEG42Wo92odNtn9C+mx+5mdDGVbX92xNYTMoiEjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739870167; c=relaxed/simple; bh=Z7vfeOXnRzH2MUW83NJ1BOZujFaF7BTid+tQ6g1426k=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=ZlcHEK4MQ2xfYBeE0nkwjxhFpMZklpq2fgS6VeIl73CTHpIzZFATFdcJ4DR3s8xfVDyBNqRkwvy+IQFPEprETr9M74HAsgcK1eNX49hJhkSujkc6qGlq4ZHioWDKGczohqo4pMvEvNTgFzUXYv5pj2iRxb5joR4BWkXbbS4K9vE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4Yxv141mCDz1wn7M; Tue, 18 Feb 2025 17:12:08 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 46C8E180214; Tue, 18 Feb 2025 17:16:02 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 18 Feb 2025 17:16:01 +0800 Message-ID: Date: Tue, 18 Feb 2025 17:16:00 +0800 Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mm: alloc_pages_bulk: remove assumption of populating only NULL elements To: Chuck Lever , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Chris Mason , Josef Bacik , David Sterba , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Carlos Maiolino , "Darrick J. Wong" , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Trond Myklebust , Anna Schumaker , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey CC: Luiz Capitulino , Mel Gorman , , , , , , , , , References: <20250217123127.3674033-1-linyunsheng@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf200006.china.huawei.com (7.185.36.61) On 2025/2/17 22:20, Chuck Lever wrote: > On 2/17/25 7:31 AM, Yunsheng Lin wrote: >> As mentioned in [1], it seems odd to check NULL elements in >> the middle of page bulk allocating, > > I think I requested that check to be added to the bulk page allocator. > > When sending an RPC reply, NFSD might release pages in the middle of It seems there is no usage of the page bulk allocation API in fs/nfsd/ or fs/nfs/, which specific fs the above 'NFSD' is referring to? > the rq_pages array, marking each of those array entries with a NULL > pointer. We want to ensure that the array is refilled completely in this > case. > I did some researching, it seems you requested that in [1]? It seems the 'holes are always at the start' for the case in that discussion too, I am not sure if the case is referring to the caller in net/sunrpc/svc_xprt.c? If yes, it seems caller can do a better job of bulk allocating pages into a whole array sequentially without checking NULL elements first before doing the page bulk allocation as something below: +++ b/net/sunrpc/svc_xprt.c @@ -663,9 +663,10 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp) pages = RPCSVC_MAXPAGES; } - for (filled = 0; filled < pages; filled = ret) { - ret = alloc_pages_bulk(GFP_KERNEL, pages, rqstp->rq_pages); - if (ret > filled) + for (filled = 0; filled < pages; filled += ret) { + ret = alloc_pages_bulk(GFP_KERNEL, pages - filled, + rqstp->rq_pages + filled); + if (ret) /* Made progress, don't sleep yet */ continue; @@ -674,7 +675,7 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp) set_current_state(TASK_RUNNING); return false; } - trace_svc_alloc_arg_err(pages, ret); + trace_svc_alloc_arg_err(pages, filled); memalloc_retry_wait(GFP_KERNEL); } rqstp->rq_page_end = &rqstp->rq_pages[pages]; 1. https://lkml.iu.edu/hypermail/linux/kernel/2103.2/09060.html 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0D791C021A9 for ; Tue, 18 Feb 2025 09:16:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ozlabs.org; s=201707; t=1739870178; bh=inAViMfXCQsf9ol1yPw8VadPDpS0D7kAWmkLjZ1Q7Cs=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=esyaeWgK0jezPSKysdQrUjLdrCwNpBQBGG1b8bOXdznzyTBG3oIH8Bws2YtA0AjN8 xx0IjIOlPEtaBz9qHzbiR54gImLmA2hKXOTG94dGjdVT4swc7eMk614IJHOF7+SQPT huioLizsapjcfYjfps1HSqZmpG2VeqGygOkEF4axyULhANjY9P79R+wJEqOm2e3fny +AN9liQAOKgyVPPlCU2nn3yO4vTdHT6mnZPOiKn4kvUpbMCBUbGUr2FlpPVAlKQ1ff CGjJO9v4qX44c+XkMuqS2W3oBWLEjj8YJ7S+vDyl9DAq3Esh9edRFtXl0LRLciKr80 vh0OlUmlL2QrQ== Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Yxv5t2vLFz3bkg for ; Tue, 18 Feb 2025 20:16:18 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=45.249.212.35 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1739870175; cv=none; b=m/5qTDBm2B40pawAKz7r8aqyyX6gyi2nKRkqnfAtm+dwCLbYeq3iQzjcY/FhNoYeoXVmkf5mLFz/9xY//XXjFhUleZ9YGy7Zn5xUdP3X/wULnk94tc1KbgR2oWJHNRe3BFNj5oIWmDpDA3O7Kh10qjJcgnXYn665A8D4W7+AgHH89+kMu61pVdN8kNuKSEtB+RSDhCV9ioeD1OTxMPbdtZQHrxeMAL508tLb6TX8/UtTJr5mOF5vRcUf4qRIYBMJEs8nTYgLGBoQEBEBkwBEjiJBBCmMweoRWUMOorBXtECOWy5o/oXOPHDHgvciNNamfxP9KsHTgs76GX0dNJ7xbg== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1739870175; c=relaxed/relaxed; bh=inAViMfXCQsf9ol1yPw8VadPDpS0D7kAWmkLjZ1Q7Cs=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=EQFUWWn8DD5dho5K29w2hg+2DGcRZSvxz/AI8U7Q6+NqVK+gmQyIoNjCpOXbA5aBqOQ2/KhSMbuSU+WiwbjY2q/dCSK3+Ghtgr4+J6YlvH6uO267Tu/FJ2GrRhvq+JV2oWtlvSMYqLLGSpcj0JzINYjsXi8AkuuSKR5aHKmoxcfMgkQgBCPniveZ8WNIt0jHpbT4Tb1ZUOFrAZBVgNj4x9K9IfykhathDpvSDJRrU9bzTGVWocEev+5/B8SpbGcQdGl/76NhfYTGEpHvLX2jZiHzBd0MGyXxwQ2iMn5AlYVX8GICilJCVp/OOFDij+FBDlFtuZ6M9cc5D4V/XGubcA== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass (client-ip=45.249.212.35; helo=szxga07-in.huawei.com; envelope-from=linyunsheng@huawei.com; receiver=lists.ozlabs.org) smtp.mailfrom=huawei.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.35; helo=szxga07-in.huawei.com; envelope-from=linyunsheng@huawei.com; receiver=lists.ozlabs.org) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Yxv5n3rHQz3039 for ; Tue, 18 Feb 2025 20:16:11 +1100 (AEDT) Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4Yxv141mCDz1wn7M; Tue, 18 Feb 2025 17:12:08 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 46C8E180214; Tue, 18 Feb 2025 17:16:02 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 18 Feb 2025 17:16:01 +0800 Message-ID: Date: Tue, 18 Feb 2025 17:16:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mm: alloc_pages_bulk: remove assumption of populating only NULL elements To: Chuck Lever , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Chris Mason , Josef Bacik , David Sterba , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Carlos Maiolino , "Darrick J. Wong" , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Trond Myklebust , Anna Schumaker , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey References: <20250217123127.3674033-1-linyunsheng@huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf200006.china.huawei.com (7.185.36.61) X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Yunsheng Lin via Linux-erofs Reply-To: Yunsheng Lin Cc: linux-nfs@vger.kernel.org, kvm@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, linux-xfs@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Mel Gorman , linux-btrfs@vger.kernel.org, Luiz Capitulino Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On 2025/2/17 22:20, Chuck Lever wrote: > On 2/17/25 7:31 AM, Yunsheng Lin wrote: >> As mentioned in [1], it seems odd to check NULL elements in >> the middle of page bulk allocating, > > I think I requested that check to be added to the bulk page allocator. > > When sending an RPC reply, NFSD might release pages in the middle of It seems there is no usage of the page bulk allocation API in fs/nfsd/ or fs/nfs/, which specific fs the above 'NFSD' is referring to? > the rq_pages array, marking each of those array entries with a NULL > pointer. We want to ensure that the array is refilled completely in this > case. > I did some researching, it seems you requested that in [1]? It seems the 'holes are always at the start' for the case in that discussion too, I am not sure if the case is referring to the caller in net/sunrpc/svc_xprt.c? If yes, it seems caller can do a better job of bulk allocating pages into a whole array sequentially without checking NULL elements first before doing the page bulk allocation as something below: +++ b/net/sunrpc/svc_xprt.c @@ -663,9 +663,10 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp) pages = RPCSVC_MAXPAGES; } - for (filled = 0; filled < pages; filled = ret) { - ret = alloc_pages_bulk(GFP_KERNEL, pages, rqstp->rq_pages); - if (ret > filled) + for (filled = 0; filled < pages; filled += ret) { + ret = alloc_pages_bulk(GFP_KERNEL, pages - filled, + rqstp->rq_pages + filled); + if (ret) /* Made progress, don't sleep yet */ continue; @@ -674,7 +675,7 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp) set_current_state(TASK_RUNNING); return false; } - trace_svc_alloc_arg_err(pages, ret); + trace_svc_alloc_arg_err(pages, filled); memalloc_retry_wait(GFP_KERNEL); } rqstp->rq_page_end = &rqstp->rq_pages[pages]; 1. https://lkml.iu.edu/hypermail/linux/kernel/2103.2/09060.html