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_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 87683C433E0 for ; Tue, 2 Feb 2021 13:52:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B5C06504A for ; Tue, 2 Feb 2021 13:52:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B5C06504A 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 52BC36B007B; Tue, 2 Feb 2021 08:52:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B6AA6B007D; Tue, 2 Feb 2021 08:52:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A5076B007E; Tue, 2 Feb 2021 08:52:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 218236B007B for ; Tue, 2 Feb 2021 08:52:58 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B2D72180AD802 for ; Tue, 2 Feb 2021 13:52:57 +0000 (UTC) X-FDA: 77773468794.27.art72_440b50b275cb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 92A2B3D663 for ; Tue, 2 Feb 2021 13:52:57 +0000 (UTC) X-HE-Tag: art72_440b50b275cb X-Filterd-Recvd-Size: 2861 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 13:52:57 +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 04A6EAC45; Tue, 2 Feb 2021 13:52:56 +0000 (UTC) Date: Tue, 2 Feb 2021 14:52:53 +0100 From: Oscar Salvador To: David Hildenbrand Cc: Andrew Morton , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] x86/vmemmap: Handle unpopulated sub-pmd ranges Message-ID: <20210202135248.GA14438@linux> References: <20210202112450.11932-1-osalvador@suse.de> <20210202112450.11932-3-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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, Feb 02, 2021 at 02:29:11PM +0100, David Hildenbrand wrote: > > @@ -1088,10 +1150,10 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end, > > pages++; > > } else { > > /* If here, we are freeing vmemmap pages. */ > > - memset((void *)addr, PAGE_INUSE, next - addr); > > + memset((void *)addr, PAGE_UNUSED, next - addr); > > page_addr = page_address(pud_page(*pud)); > > - if (!memchr_inv(page_addr, PAGE_INUSE, > > + if (!memchr_inv(page_addr, PAGE_UNUSED, > > PUD_SIZE)) { > > free_pagetable(pud_page(*pud), > > get_order(PUD_SIZE)); > > I'm sorry to bother you again, but isn't that dead code as well? Heh, I spotted that earlier, but I did not think much of it honestly. All this was introduced by: commit ae9aae9eda2db71bf4b592f15618b0160eb07731 Author: Wen Congyang Date: Fri Feb 22 16:33:04 2013 -0800 memory-hotplug: common APIs to support page tables hot-remove > How do we ever end up using 1GB pages for the vmemmap? At least not via > vmemmap_populate() - so I guess never? There are not many occurrences of > "PUD_SIZE" in the file after all ... AFAICT, we don't. The largest we populate for vmemmap is 2MB. I see init_memory_mapping can use 1G, but that should not affect us. I guess that the vmemmap handling for 1GB can go as well. I will update the patchset. -- Oscar Salvador SUSE L3