From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (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 72A121F8F1C for ; Fri, 3 Jan 2025 11:22:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735903323; cv=none; b=p1PSkaol+I7raGaSROcHZFXHDKh8cWnL8ccnw7tYYMYDvkcrjiENVpOy5zEFdeQkMHzm+pQ0yKueN9y5/cYyOAPWDE4HGJCo0gj+kTWnpzolAaiLIBHSh5CTW4+bKgDKF2wnTwAxER6eAJomIh/nfKZyomYSg7hz4fWr48FpXFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735903323; c=relaxed/simple; bh=NGzrbe31+YLVcawQKxBEmvATpRE6Zkv0/3oUPiUkgg8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=s4aj8rt8T+1Dk9xMp2/dRw73lnLNf+QbyTQcALzXTT2WW+Q20AyjO7nE7w4Ypop9EYHRZXWJZQHLEiGkqGJ/hsK/UIj+Ey+FRCHGouk1UEaiAjHfNIzylX/OmXs2UH/NtlThv++LGC8jwYq0jcs4jweVqSBNMAdgDcHu4iQlPrQ= 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.32 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.163.44]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4YPh4X3sGVz20nM2; Fri, 3 Jan 2025 19:22:20 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id CD47B1402DA; Fri, 3 Jan 2025 19:21:58 +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; Fri, 3 Jan 2025 19:21:58 +0800 Message-ID: <0edbfcf5-db26-441f-ae9c-f85985cb8b68@huawei.com> Date: Fri, 3 Jan 2025 19:21:58 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] mm: alloc_pages_bulk_noprof: drop page_list argument To: Luiz Capitulino , , , CC: , , References: Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) On 2025/1/3 0:38, Luiz Capitulino wrote: > On 2024-12-25 07:36, Yunsheng Lin wrote: >> On 2024/12/24 6:00, Luiz Capitulino wrote: >> >>>   /* >>> - * __alloc_pages_bulk - Allocate a number of order-0 pages to a list or array >>> + * __alloc_pages_bulk - Allocate a number of order-0 pages to an array >>>    * @gfp: GFP flags for the allocation >>>    * @preferred_nid: The preferred NUMA node ID to allocate from >>>    * @nodemask: Set of nodes to allocate from, may be NULL >>> - * @nr_pages: The number of pages desired on the list or array >>> - * @page_list: Optional list to store the allocated pages >>> - * @page_array: Optional array to store the pages >>> + * @nr_pages: The number of pages desired in the array >>> + * @page_array: Array to store the pages >>>    * >>>    * This is a batched version of the page allocator that attempts to >>> - * allocate nr_pages quickly. Pages are added to page_list if page_list >>> - * is not NULL, otherwise it is assumed that the page_array is valid. >>> + * allocate nr_pages quickly. Pages are added to the page_array. >>>    * >>> - * For lists, nr_pages is the number of pages that should be allocated. >>> - * >>> - * For arrays, only NULL elements are populated with pages and nr_pages >>> + * Note that only NULL elements are populated with pages and nr_pages >> >> It is not really related to this patch, but while we are at this, the above >> seems like an odd behavior. By roughly looking at all the callers of that >> API, it seems like only the below callers rely on that? >> fs/erofs/zutil.c: z_erofs_gbuf_growsize() >> fs/xfs/xfs_buf.c: xfs_buf_alloc_pages() >> >> It seems it is quite straight forward to change the above callers to not >> rely on the above behavior, and we might be able to avoid more checking >> by removing the above behavior? > > Hi Yunsheng, > > Assuming the use-case is valid, I think we might want to keep common code > in the API vs. duplicating it in callers? I was thinking maybe adding a wrapper/helper around the __alloc_pages_bulk() to avoid the overhead for other usecase and make the semantics more obvious if it is an valid use-case. > > In any case, even if we decide to go for your suggestion, I'd prefer not > to grow the scope of this series since this could delay its inclusion. > Dropping the list-API (and dead code) is actually important so IMHO it > should go in first. Sure. >