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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 14859C433DB for ; Mon, 22 Mar 2021 23:04:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 866F5619A4 for ; Mon, 22 Mar 2021 23:04:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 866F5619A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C0CD36B0116; Mon, 22 Mar 2021 19:04:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B95C46B0117; Mon, 22 Mar 2021 19:04:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C0756B0118; Mon, 22 Mar 2021 19:04:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 7C6756B0116 for ; Mon, 22 Mar 2021 19:04:26 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 43BE6180AD802 for ; Mon, 22 Mar 2021 23:04:26 +0000 (UTC) X-FDA: 77949040932.37.88E9EF5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 68AFE80192F3 for ; Mon, 22 Mar 2021 23:04:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=I/Fi+CHBqKtMivDDdq6/vIEH2z4t0eGQsQY2LUIfIms=; b=r68kn1K6n888jPXvJhttLzOxFJ vR74kWBhN43KiWf4FYFcUD5tg6ItXUIB6HYtcLKQ6+xYHjxF74UZQbDxm4vC/MpV8JSKa2lhxU8HP 6joA1yyGOJmxNlwkxsWIp3lQNfiMzLqcVkoC/lZOrb3P4Kfd8dO5F7AC2f4KfptYJmWyFmiFB6iT9 Ie5BzSx1Vc+zxzF8prcIWzXviaUachc2ih6XZpxetphg+TmWJ/DILwyF98RiPABp4G7m0g0ZEP6ea r078cKqr4h1I9SQdrRy/UfHKERTbAhvORLf4QBOfFiE841xXowqxv6CpXeu+WHlyJ85PDOUxM4czD 3Gcf7LKQ==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lOTZn-009Cq8-6E; Mon, 22 Mar 2021 23:03:21 +0000 Date: Mon, 22 Mar 2021 23:03:11 +0000 From: Matthew Wilcox To: Uladzislau Rezki Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nicholas Piggin Subject: Re: [PATCH 2/2] mm/vmalloc: Use kvmalloc to allocate the table of pages Message-ID: <20210322230311.GY1719932@casper.infradead.org> References: <20210322193820.2140045-1-willy@infradead.org> <20210322193820.2140045-2-willy@infradead.org> <20210322223619.GA56503@pc638.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210322223619.GA56503@pc638.lan> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 68AFE80192F3 X-Stat-Signature: 1ep1hqhcpx8sit374br6z4ti5gudejo1 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616454261-481154 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 Mon, Mar 22, 2021 at 11:36:19PM +0100, Uladzislau Rezki wrote: > On Mon, Mar 22, 2021 at 07:38:20PM +0000, Matthew Wilcox (Oracle) wrote: > > If we're trying to allocate 4MB of memory, the table will be 8KiB in size > > (1024 pointers * 8 bytes per pointer), which can usually be satisfied > > by a kmalloc (which is significantly faster). Instead of changing this > > open-coded implementation, just use kvmalloc(). > > > > Signed-off-by: Matthew Wilcox (Oracle) > > --- > > mm/vmalloc.c | 7 +------ > > 1 file changed, 1 insertion(+), 6 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 96444d64129a..32b640a84250 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2802,13 +2802,8 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > > gfp_mask |= __GFP_HIGHMEM; > > > > /* Please note that the recursion is strictly bounded. */ > > - if (array_size > PAGE_SIZE) { > > - pages = __vmalloc_node(array_size, 1, nested_gfp, node, > > + pages = kvmalloc_node_caller(array_size, nested_gfp, node, > > area->caller); > > - } else { > > - pages = kmalloc_node(array_size, nested_gfp, node); > > - } > > - > > if (!pages) { > > free_vm_area(area); > > return NULL; > > -- > > 2.30.2 > Makes sense to me. Though i expected a bigger difference: > > # patch > single CPU, 4MB allocation, loops: 1000000 avg: 85293854 usec > > # default > single CPU, 4MB allocation, loops: 1000000 avg: 89275857 usec Well, 4.5% isn't something to leave on the table ... but yeah, I was expecting more in the 10-20% range. It may be more significant if there's contention on the spinlocks (like if this crazy ksmbd is calling vmalloc(4MB) on multiple nodes simultaneously). I suspect the vast majority of the time is spent calling alloc_pages_node() 1024 times. Have you looked at Mel's patch to do ... well, exactly what vmalloc() wants? https://lore.kernel.org/linux-mm/20210322091845.16437-1-mgorman@techsingularity.net/ > One question. Should we care much about fragmentation? I mean > with the patch, allocations > 2MB will do request to SLAB bigger > then PAGE_SIZE. We're pretty good about allocating memory in larger chunks these days. Looking at my laptop's slabinfo, kmalloc-8k 219 232 8192 4 8 : tunables 0 0 0 : sla bdata 58 58 0 That's using 8 pages per slab, so that's order-3 allocations. There's a few more of those: $ sudo grep '8 :' /proc/slabinfo |wc 42 672 4508 so I have confidence that kvmalloc() will manage to use kmalloc up to 16MB vmalloc allocations, and after that it'll tend to fall back to vmalloc.