Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4370275pxf; Tue, 23 Mar 2021 09:02:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7BoSIfGLGuAfnE4V8uDGwBLc5b9aEU8fHmAW2/brBUVam82r2V+U9cLB5lWHzVEhLbz8o X-Received: by 2002:a5d:564a:: with SMTP id j10mr4649215wrw.120.1616515337258; Tue, 23 Mar 2021 09:02:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616515337; cv=none; d=google.com; s=arc-20160816; b=a4LgzIvNbw1hSz8xQh5oAL6qRtLOUmRbe5hfxVEExAJ6PGWIPFPFMQShSj1wBp7t6G 2QlUHQJqQdP5k+QIyyy6YzMaa1TW0H1N94Ru6G5/pnVv3qlqaDs0i05C34fhrmNuogiH YNXo/O+dqR/dzWqj7P2lBHR+pxv8cLQhjggquERw0XUjrtGYEzTOfAcEn9ydz2kHEPJ8 kQt25Ks5VQzJw88SmVXT5Mj1JyltH268g55JwPilCMDTivweMjlqHXSp+DN9zwZ/iWho 8OZ/RkZRggNplq/NXnhj881ZjAyd1EM++F2kPLDd1n2kaoX5mhU8uHXFIHKdQSPHaVEg c24A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=ag6revSYuTWYgiFkSHVLZKeNOhSbXqduzMFpfyyQ8KU=; b=ZKCSC8bkkYo59YwP/1qFzdV+CP4uFkbDtLEd3LbWRPVAU2gXQqYgwm6KulUBxTXjwy n5r0S7wY8/dvhpnHB+OuwEfdR2gMPxu/5D8hxRTQViHZ9TI3lzCMEIlAGJVjh0nTMVgR P1NVlTpl8DsrYbkRqqb5XLRZ7ZMxzw2DXLKdf67Sv9xgf4Y9S63+OkJrDXCOQxPeLsBX 1dIHz4y23QR9qJhkTFOufi/6YXhiJdeXcbz6XtZxP9cSkDDGxZGBjOS0JHEe6b2nhXO0 JyBxN1xyhuPa8U1HekTX4od+hDu6Bn4ASM/wyvAH7gTYtWCGav93wL/YoUE/ABIzj7Pe wrFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RUfIiHI7; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s20si14216508edq.484.2021.03.23.09.01.51; Tue, 23 Mar 2021 09:02:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RUfIiHI7; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232888AbhCWQAf (ORCPT + 99 others); Tue, 23 Mar 2021 12:00:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46183 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232963AbhCWQAX (ORCPT ); Tue, 23 Mar 2021 12:00:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616515222; 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=ag6revSYuTWYgiFkSHVLZKeNOhSbXqduzMFpfyyQ8KU=; b=RUfIiHI7OhXECbxf9eC59a2Y01xW2UvIVgOe2XlsPpUruN1OMJjUHa8CCYjEyXwYq+PW/O S7ekSNk8cNz6L3rQcl7/r3+Dw03UY2SAN5wFKqLgN5wLPTwvi8geIxYJ1leUrjTnfrU5Hd 04xDpDnRc+Wkmo3cBjKjWMsqypibhR0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-475-9STvXw5dMGaqTJ0Ho9AYAg-1; Tue, 23 Mar 2021 12:00:18 -0400 X-MC-Unique: 9STvXw5dMGaqTJ0Ho9AYAg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4FECF1013721; Tue, 23 Mar 2021 16:00:16 +0000 (UTC) Received: from carbon (unknown [10.36.110.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E4A85D6AD; Tue, 23 Mar 2021 16:00:09 +0000 (UTC) Date: Tue, 23 Mar 2021 17:00:08 +0100 From: Jesper Dangaard Brouer To: Mel Gorman Cc: Andrew Morton , Vlastimil Babka , Chuck Lever , Christoph Hellwig , Alexander Duyck , Matthew Wilcox , LKML , Linux-Net , Linux-MM , Linux-NFS , brouer@redhat.com Subject: Re: [PATCH 2/3] mm/page_alloc: Add a bulk page allocator Message-ID: <20210323170008.5d0732be@carbon> In-Reply-To: <20210322091845.16437-3-mgorman@techsingularity.net> References: <20210322091845.16437-1-mgorman@techsingularity.net> <20210322091845.16437-3-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, 22 Mar 2021 09:18:44 +0000 Mel Gorman wrote: > This patch adds a new page allocator interface via alloc_pages_bulk, > and __alloc_pages_bulk_nodemask. A caller requests a number of pages > to be allocated and added to a list. > > The API is not guaranteed to return the requested number of pages and > may fail if the preferred allocation zone has limited free memory, the > cpuset changes during the allocation or page debugging decides to fail > an allocation. It's up to the caller to request more pages in batch > if necessary. > > Note that this implementation is not very efficient and could be improved > but it would require refactoring. The intent is to make it available early > to determine what semantics are required by different callers. Once the > full semantics are nailed down, it can be refactored. > > Signed-off-by: Mel Gorman > Acked-by: Vlastimil Babka > --- > include/linux/gfp.h | 11 ++++ > mm/page_alloc.c | 124 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 135 insertions(+) [...] > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 8a3e13277e22..3f4d56854c74 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4965,6 +4965,130 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order, > return true; > } > > +/* > + * __alloc_pages_bulk - Allocate a number of order-0 pages to a list > + * @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 requested > + * @page_list: List to store the allocated pages, must be empty > + * > + * This is a batched version of the page allocator that attempts to > + * allocate nr_pages quickly and add them to a list. The list must be > + * empty to allow new pages to be prepped with IRQs enabled. > + * > + * Returns the number of pages allocated. > + */ > +int __alloc_pages_bulk(gfp_t gfp, int preferred_nid, > + nodemask_t *nodemask, int nr_pages, > + struct list_head *page_list) > +{ [...] > + /* > + * If there are no allowed local zones that meets the watermarks then > + * try to allocate a single page and reclaim if necessary. > + */ > + if (!zone) > + goto failed; > + > + /* Attempt the batch allocation */ > + local_irq_save(flags); > + pcp = &this_cpu_ptr(zone->pageset)->pcp; > + pcp_list = &pcp->lists[ac.migratetype]; > + > + while (allocated < nr_pages) { > + page = __rmqueue_pcplist(zone, ac.migratetype, alloc_flags, > + pcp, pcp_list); The function __rmqueue_pcplist() is now used two places, this cause the compiler to uninline the static function. My tests show you should inline __rmqueue_pcplist(). See patch I'm using below signature, which also have some benchmark notes. (Please squash it into your patch and drop these notes). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer [PATCH] mm: inline __rmqueue_pcplist From: Jesper Dangaard Brouer When __alloc_pages_bulk() got introduced two callers of __rmqueue_pcplist exist and the compiler chooses to not inline this function. ./scripts/bloat-o-meter vmlinux-before vmlinux-inline__rmqueue_pcplist add/remove: 0/1 grow/shrink: 2/0 up/down: 164/-125 (39) Function old new delta rmqueue 2197 2296 +99 __alloc_pages_bulk 1921 1986 +65 __rmqueue_pcplist 125 - -125 Total: Before=19374127, After=19374166, chg +0.00% modprobe page_bench04_bulk loops=$((10**7)) Type:time_bulk_page_alloc_free_array - Per elem: 106 cycles(tsc) 29.595 ns (step:64) - (measurement period time:0.295955434 sec time_interval:295955434) - (invoke count:10000000 tsc_interval:1065447105) Before: - Per elem: 110 cycles(tsc) 30.633 ns (step:64) Signed-off-by: Jesper Dangaard Brouer --- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 2cbb8da811ab..f60f51a97a7b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3415,7 +3415,8 @@ static inline void zone_statistics(struct zone *preferred_zone, struct zone *z) } /* Remove page from the per-cpu list, caller must protect the list */ -static struct page *__rmqueue_pcplist(struct zone *zone, int migratetype, +static inline +struct page *__rmqueue_pcplist(struct zone *zone, int migratetype, unsigned int alloc_flags, struct per_cpu_pages *pcp, struct list_head *list)