From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 4619914D2BD for ; Fri, 3 Jan 2025 14:13:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735913591; cv=none; b=i+NoPc2rxVQVw7WqZ0h0pf1nNA7gHe0XlP5rWS1V0bQ+q4F7H9zXE452S/U2HN80ChjSLxVXETaCtPgk97QXpzYSkZkV/osMHSGVQrL2aHH1NVBmooYyOsIMhrbvGTSXTxQkLzfX/849brXncPAAnq9ax3Fn0v1WyxfbCOLBnnE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735913591; c=relaxed/simple; bh=5cxWbrmU26cdCmUhp9mTEfBHL9rghwTJC4w5UrRrVyU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W6ruRLHh7CXrFGCemdKxoK5uMp3xWHXAec6gwgE6wgRBlJs0G5e0JWYDf3Nbs+PyILcphA4IDxR+43Cq6NYDyX1UY9MytS97RuKTgsGwoq/uRMSgb5BdUbjONWi1BRuNCmVITcAl0xepRovEageIrVw7jMl1RTORJDBp32EaIzo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DnT5ZHNm; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DnT5ZHNm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735913586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q50EBBo/WOeLAs8/4dtu+U+Qr48eaJOvxqJ8fJgshjY=; b=DnT5ZHNmXmvjictjDA0ldE5zIaB8Imgd59G8nnlO+3GzGQCi1VorHnf/77v1LcryEkBimI CLw0TGgjdAnvB2AKGe2DnRyMsFi1OUB4jsilwHwV2n5NEaR48qdLllxiYvn15jj5AKgE9t bJhshBSd1+tHrKk1knuneaSp34YrVGI= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-324-Cf85PdpaOHO22yQSFfM3eQ-1; Fri, 03 Jan 2025 09:13:04 -0500 X-MC-Unique: Cf85PdpaOHO22yQSFfM3eQ-1 X-Mimecast-MFC-AGG-ID: Cf85PdpaOHO22yQSFfM3eQ Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6dcf01612f0so101751256d6.3 for ; Fri, 03 Jan 2025 06:13:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735913584; x=1736518384; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q50EBBo/WOeLAs8/4dtu+U+Qr48eaJOvxqJ8fJgshjY=; b=ZxagsdtqQ3xJPfXWAPVEVKaDwq6aNFzvNLnogHfP8rvusgJb3E70QJac2VnfgY1Ajg ul4sV6IL/H3penPKj5tDfD7XAd9Y1j9qPHhvckbLbaZRk+0EPWhu+UMBw3B+KVIfBdT6 JP90BL4XgqT9dXWhZDfj+QeOCE3R2YjYghYNYPT049tfM0TAFsafMvadyz1YlMPZ2BYn bHz9ajESMpCCo4rXY3b8Jx9vbmkJPRQ1npvC+eMN0jhmxxw+icYPH2tz2QTuTD3Akp2k tt/E2nJtU0lM/6mY63CF53ccxXNlwEJXOyx4+vgzQ986xBnnabNT+ScroRunuK7e5KwK m0ww== X-Forwarded-Encrypted: i=1; AJvYcCWBzW7Ksr12AZoNO8hdvKNP0QMTvQe3uLnhGOdsExnymaejbs2GzL2/qdDY5NDnNfJRq0KM4ykyTXM88D4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy7knUj4efalmNa/k20Qt3RepE81dZpFdqPJ9dvR6G0HxPROKO9 noGI/imLWwscQzIZ9leXk83lqn+jleJGkFjIsApmbg//osQm7DuIYXXGapWYDYz3NN+so0qMGGl iKACr3jx9+Gl9ip3+2KbruvbBhZS2LzrDroNdQAPV0CyjtKK2ATDDYoIYE7vTmA== X-Gm-Gg: ASbGncv0gyccZpGVBUHUGvGmfkn3Urj0bs92gDEEHYYn6zPHCfSR1/WAOz/uWF/usa0 DMuQEfUFxWxr/gmPoQ7e3DWs8BKRuS68J0I8p+mgtAldwyhzrCTKExJUGWKqjTzJ0R4aVfNJLM/ x448FtwqWOGQLQJvGkkYaVdNNLqDWybk7S4/gk9vDZJJ90acumBrx5Z/9xtsR05tFWU5VJ/swkx 2P6DJhHGAMcKqz+BkitY4ah07TgI0dYEgE9DKKZlZymi54trXPVvtUq X-Received: by 2002:a05:6214:d42:b0:6d4:139c:cef0 with SMTP id 6a1803df08f44-6dd233545f9mr613361356d6.22.1735913584388; Fri, 03 Jan 2025 06:13:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IGfkd/y94j3GT4Wbl+HKoDQCS+Wdl4LTiVrVxLBddmSAc40Cv3s1aAQJ8NSfXvBDEghvCYI7Q== X-Received: by 2002:a05:6214:d42:b0:6d4:139c:cef0 with SMTP id 6a1803df08f44-6dd233545f9mr613361166d6.22.1735913584092; Fri, 03 Jan 2025 06:13:04 -0800 (PST) Received: from [192.168.2.110] ([70.52.22.87]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd18110112sm141968806d6.33.2025.01.03.06.13.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jan 2025 06:13:03 -0800 (PST) Message-ID: <84b5ad54-8765-4a38-a032-ca7fb9978c2d@redhat.com> Date: Fri, 3 Jan 2025 09:12:52 -0500 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: Yunsheng Lin , linux-mm@kvack.org, mgorman@techsingularity.net, willy@infradead.org Cc: david@redhat.com, linux-kernel@vger.kernel.org, lcapitulino@gmail.com References: <0edbfcf5-db26-441f-ae9c-f85985cb8b68@huawei.com> Content-Language: en-US, en-CA From: Luiz Capitulino In-Reply-To: <0edbfcf5-db26-441f-ae9c-f85985cb8b68@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025-01-03 06:21, Yunsheng Lin wrote: > 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. Yeah, that might be a good idea. > >> >> 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. > >> >