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 6041717993 for ; Wed, 25 Dec 2024 12:53:01 +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=1735131184; cv=none; b=oelAYG2Nn836k1nIguCHeRz1genSQ9PmGlBsRLPB/8CPrqJmQL0F/orsiSC4Khn51iP6Q9TIsjLMavNko+BpQB4CjFrDu9UN183CSU5Dwj1p4dsz5TB6WIQMIHFD2Qt0bRcG44vo2KolLDaanbwZsq9FudPdsYfyjq5KhC4ySaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735131184; c=relaxed/simple; bh=1JpsR0Yczh7Y/Vhyrk0xlpvMldecRs7CQe1MAwlXz8k=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=kNnlmvQnm/o4YUFbYPn/421omMGtyfu3czWgxUUr+O9NSY4owlWK0rncaD9CORCm4SUlKd9CX+X47gXKp17P2eqoghVrjGWxGfD+8gWl9QfNKuc+F3KZ/RIYkA4GK3sR5NpgNAbpWY+djPFSUMx2DF+WVLQ/PsnMedk52d9GjDk= 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 4YJB4k5X2qz1T7JG; Wed, 25 Dec 2024 20:33:26 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 10C5718001B; Wed, 25 Dec 2024 20:36:11 +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; Wed, 25 Dec 2024 20:36:10 +0800 Message-ID: Date: Wed, 25 Dec 2024 20:36:04 +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: 7bit X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemf200006.china.huawei.com (7.185.36.61) 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? > * is the maximum number of pages that will be stored in the array. > * > - * Returns the number of pages on the list or array. > + * Returns the number of pages in the array. > */ > unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid, > nodemask_t *nodemask, int nr_pages, > - struct list_head *page_list, > struct page **page_array) > { > struct page *page; > @@ -4570,7 +4565,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid, > * Skip populated array elements to determine if any pages need > * to be allocated before disabling IRQs. > */ > - while (page_array && nr_populated < nr_pages && page_array[nr_populated]) > + while (nr_populated < nr_pages && page_array[nr_populated]) > nr_populated++; The above might be avoided as mentioned above. > > /* No pages requested? */ > @@ -4578,7 +4573,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid, > goto out; > > /* Already populated array? */ > - if (unlikely(page_array && nr_pages - nr_populated == 0)) > + if (unlikely(nr_pages - nr_populated == 0)) > goto out; > > /* Bulk allocator does not support memcg accounting. */ > @@ -4660,7 +4655,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid, > while (nr_populated < nr_pages) { > > /* Skip existing pages */ > - if (page_array && page_array[nr_populated]) { > + if (page_array[nr_populated]) { Similar here. > nr_populated++; > continue; > }