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 X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3385C433ED for ; Mon, 17 May 2021 08:24:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 737BF611CA for ; Mon, 17 May 2021 08:24:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 737BF611CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0275F6B0036; Mon, 17 May 2021 04:24:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1A1D6B006E; Mon, 17 May 2021 04:24:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB9F96B0070; Mon, 17 May 2021 04:24:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id A54D16B0036 for ; Mon, 17 May 2021 04:24:54 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 31CAE181AF5F7 for ; Mon, 17 May 2021 08:24:54 +0000 (UTC) X-FDA: 78150037308.26.4A313A6 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf27.hostedemail.com (Postfix) with ESMTP id 2B67A80192C6 for ; Mon, 17 May 2021 08:24:52 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 763A3AF16; Mon, 17 May 2021 08:24:52 +0000 (UTC) Date: Mon, 17 May 2021 09:24:50 +0100 From: Mel Gorman To: "Uladzislau Rezki (Sony)" Cc: Andrew Morton , linux-mm@kvack.org, LKML , Matthew Wilcox , Nicholas Piggin , Hillf Danton , Michal Hocko , Oleksiy Avramchenko , Steven Rostedt Subject: Re: [PATCH 2/3] mm/vmalloc: Switch to bulk allocator in __vmalloc_area_node() Message-ID: <20210517082449.GT3672@suse.de> References: <20210516202056.2120-1-urezki@gmail.com> <20210516202056.2120-3-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210516202056.2120-3-urezki@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf27.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.15 as permitted sender) smtp.mailfrom=mgorman@suse.de X-Stat-Signature: kxa5u6genfhw7t3antgkewjmp3zwicn7 X-Rspamd-Queue-Id: 2B67A80192C6 X-Rspamd-Server: rspam02 X-HE-Tag: 1621239892-216646 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, May 16, 2021 at 10:20:55PM +0200, Uladzislau Rezki (Sony) wrote: > Recently there has been introduced a page bulk allocator for > users which need to get number of pages per one call request. > > For order-0 pages switch to an alloc_pages_bulk_array_node() > instead of alloc_pages_node(), the reason is the former is > not capable of allocating set of pages, thus a one call is > per one page. > > Second, according to my tests the bulk allocator uses less > cycles even for scenarios when only one page is requested. > Running the "perf" on same test case shows below difference: > > > - 45.18% __vmalloc_node > - __vmalloc_node_range > - 35.60% __alloc_pages > - get_page_from_freelist > 3.36% __list_del_entry_valid > 3.00% check_preemption_disabled > 1.42% prep_new_page > > > > - 31.00% __vmalloc_node > - __vmalloc_node_range > - 14.48% __alloc_pages_bulk > 3.22% __list_del_entry_valid > - 0.83% __alloc_pages > get_page_from_freelist > > > The "test_vmalloc.sh" also shows performance improvements: > > fix_size_alloc_test_4MB loops: 1000000 avg: 89105095 usec > fix_size_alloc_test loops: 1000000 avg: 513672 usec > full_fit_alloc_test loops: 1000000 avg: 748900 usec > long_busy_list_alloc_test loops: 1000000 avg: 8043038 usec > random_size_alloc_test loops: 1000000 avg: 4028582 usec > fix_align_alloc_test loops: 1000000 avg: 1457671 usec > > fix_size_alloc_test_4MB loops: 1000000 avg: 62083711 usec > fix_size_alloc_test loops: 1000000 avg: 449207 usec > full_fit_alloc_test loops: 1000000 avg: 735985 usec > long_busy_list_alloc_test loops: 1000000 avg: 5176052 usec > random_size_alloc_test loops: 1000000 avg: 2589252 usec > fix_align_alloc_test loops: 1000000 avg: 1365009 usec > > For example 4MB allocations illustrates ~30% gain, all the > rest is also better. > > Signed-off-by: Uladzislau Rezki (Sony) FWIW, it passed build and boot tests. Acked-by: Mel Gorman -- Mel Gorman SUSE Labs