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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 30786C432BE for ; Wed, 1 Sep 2021 07:22:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ABC4761059 for ; Wed, 1 Sep 2021 07:22:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ABC4761059 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 42BDD6B006C; Wed, 1 Sep 2021 03:22:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DB386B0071; Wed, 1 Sep 2021 03:22:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C9538D0001; Wed, 1 Sep 2021 03:22:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 1B2E36B006C for ; Wed, 1 Sep 2021 03:22:53 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B2D052775C for ; Wed, 1 Sep 2021 07:22:52 +0000 (UTC) X-FDA: 78538162584.26.AE04A8C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 57391100009E for ; Wed, 1 Sep 2021 07:22:52 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DAB4B60E98; Wed, 1 Sep 2021 07:22:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630480971; bh=ROvubnIZ7CG7NtmC524Rg5/WiRX8ZoyaERotUEZbRL0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OwvGS0g9Rk3Sbnr9PqhqnIqsnpglwcimyj5PYWZl+ld0I8CY15MKMWHd3uVhtm18y DXLWffZNKZCSjJ8MwZVNT4VI130Pw8HnmI1QDiG8OZafTNCe3l/J1Ck1ZXFGIrPrSU iW5bZiqaaPZkiTXAqz3RcDIyqE2xSDcKxm57tPE83v8pIPwp2+xP3lRaYHWo4/M9na i5AaXBZHxFAJdF4sv7rwX33WBPT6fOVKQJVlZXJJK8Jn9D8e/ml2Jhye3d88jqtHVw qJ1ivQ9AhefJSJF9A5hafWAMdfJRsLXUNDadIIMh4dglT0cmfW1f8BVhpF1m9biuBY +bKu2nmjT8KOg== Date: Wed, 1 Sep 2021 10:22:44 +0300 From: Mike Rapoport To: "Edgecombe, Rick P" Cc: "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "keescook@chromium.org" , "Weiny, Ira" , "linux-hardening@vger.kernel.org" , "linux-mm@kvack.org" , "vbabka@suse.cz" , "x86@kernel.org" , "akpm@linux-foundation.org" , "Williams, Dan J" , "Lutomirski, Andy" , "kernel-hardening@lists.openwall.com" , "Hansen, Dave" , "shakeelb@google.com" Subject: Re: [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations Message-ID: References: <20210830235927.6443-1-rick.p.edgecombe@intel.com> <20210830235927.6443-12-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OwvGS0g9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 57391100009E X-Stat-Signature: zkwsfqcnb74zn4h68x4nar6pgh983aqc X-HE-Tag: 1630480972-766697 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 Tue, Aug 31, 2021 at 06:25:23PM +0000, Edgecombe, Rick P wrote: > On Tue, 2021-08-31 at 11:55 +0300, Mike Rapoport wrote: > > On Mon, Aug 30, 2021 at 04:59:19PM -0700, Rick Edgecombe wrote: > > > > -static void * __meminit vmemmap_alloc_block_zero(unsigned long > > > size, int node) > > > +static void * __meminit vmemmap_alloc_table(int node) > > > { > > > - void *p = vmemmap_alloc_block(size, node); > > > + void *p; > > > + if (slab_is_available()) { > > > + struct page *page = alloc_table_node(GFP_KERNEL | > > > __GFP_ZERO, node); > > > > This change removes __GFP_RETRY_MAYFAIL|__GFP_NOWARN from the > > original gfp > > vmemmap_alloc_block() used. > Oh, yea good point. Hmm, I guess grouped pages could be aware of that > flag too. Would be a small addition, but it starts to grow > unfortunately. > > > Not sure __GFP_RETRY_MAYFAIL is really needed in > > vmemmap_alloc_block_zero() > > at the first place, though. > Looks like due to a real issue: > 055e4fd96e95b0eee0d92fd54a26be7f0d3bcad0 I believe the issue was with memory map blocks rather than with page tables, but since sparse-vmemmap uses the same vmemmap_alloc_block() for both, the GFP flag got stick with both. I'm not really familiar with reclaim internals to say if __GFP_RETRY_MAYFAIL would help much for order-0 allocation. Vlastimil, can you comment on this? > I think it should not affect PKS tables for now, so maybe I can make > separate logic instead. I'll look into it. Thanks. > > > > More broadly, maybe it makes sense to split boot time and memory > > hotplug > > paths and use pxd_alloc() for the latter. > > > > > + > > > + if (!page) > > > + return NULL; > > > + return page_address(page); > > > + } > > > > > > + p = __earlyonly_bootmem_alloc(node, PAGE_SIZE, PAGE_SIZE, > > > __pa(MAX_DMA_ADDRESS)); > > > > Opportunistically rename to __earlyonly_memblock_alloc()? ;-) > > > Heh, I can. Just grepping, there are several other instances of > foo_bootmem() only calling foo_memblock() pattern scattered about. Or > maybe I'm missing the distinction. Heh, I didn't do s/bootmem/memblock/g, so foo_bootmem() are reminders we had bootmem allocator once. Maybe it's a good time to remove them :) > -- Sincerely yours, Mike.