Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3461442pxb; Mon, 25 Jan 2021 17:33:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJzQIGsMk3YSh8KnTUco3uwhmXH8tcbDzSoCP5kNpKs3PxQXjoBgduBwURigJNWMZzad6hIn X-Received: by 2002:a05:6402:1b11:: with SMTP id by17mr2606148edb.373.1611624787875; Mon, 25 Jan 2021 17:33:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611624787; cv=none; d=google.com; s=arc-20160816; b=WdMDqK3OlXDasHsL8GCcWq/1d6DnlcRPw5pu44nA80n4+O+Y61d8AIjwdBtaQ8tctB C7DYZvYEf9wYWIl658SokbrOJJNwS5LxvcEWiCn4uGvfZK2A4LLLZtdMlRnqmSOXTKI4 iY6cyGdZaJeLOQAxhfqWmGWEJ7FIJ1E4bWIe7mDGOrySfkDpvBcpxBfzCxGQixD+kCPr 3fBPeoOw0spGj9vybYnpf+2pDJTDNtmVZqLUuyUQVAj7LP9RHX6raDF78Kdyg63vZqF7 S8n0WDbqSxUcP8GiUGLBFqWe+nFzr9GidjdKS8Piz50NWTGRQsTPM4hTvzr/Zv7qf/DQ R38w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=DrrsduXw40spa9C0cPD/Y3KujjjqBKpfWwF9zUNXpbE=; b=pns9HOlvBUNgGtGP2Sg1YeT+f4YVbrgCyvhmzAg3W8lkdp1Ac5kVCDCN16V8v6dzUN H7HlYAPFBdptDotzKWaUSsT/CAkegXp2bL9DOBpNTLVAXxGCKLHIzuSmvfB3P6jQivtz inz8KzwU+VG/k1CtyNrG/2vnR4LKdNFgPwEIf7XO0xsxMaN1YU3E0Iu8bQ5fjWIIcnKA ILGlElKJzYbyWwNX3VgJ6gRcLWxiGl1HrVtJ3U2aliTaSMWW9DLlptLFuw84UdyqJTCy Z6BIxW94Ixqi4/ypZKmpHD//9OIZ6TQ8d+4sp+IPCQFuyLaDYs2s0Fy5IcasjbD4m7E/ +dOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=StpZjeMx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 o28si7968071edz.348.2021.01.25.17.32.43; Mon, 25 Jan 2021 17:33:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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=StpZjeMx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 S1728618AbhAYNJN (ORCPT + 99 others); Mon, 25 Jan 2021 08:09:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:34380 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728545AbhAYM64 (ORCPT ); Mon, 25 Jan 2021 07:58:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611579421; 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=DrrsduXw40spa9C0cPD/Y3KujjjqBKpfWwF9zUNXpbE=; b=StpZjeMxx7xC2CGUa30pgzVOFXbICm63Z0O6HaAKdVG/JBY0+4zvljvpfFB/j/H0oSS6P2 qwm3HDADRjFIG6BD5xvpVB9oRS3edjexRbJcP+rd0j3ywSx4kuUpVfU5AQ0St+JB6rMkzL coNFCOTjMA+N1/orBMQpae8zjQhP0LM= 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-92-OndNxk3gOOqLsuKiAZjAQQ-1; Mon, 25 Jan 2021 06:43:34 -0500 X-MC-Unique: OndNxk3gOOqLsuKiAZjAQQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CFE6618C8C0E; Mon, 25 Jan 2021 11:43:30 +0000 (UTC) Received: from [10.36.115.13] (ovpn-115-13.ams2.redhat.com [10.36.115.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2BE4D19C44; Mon, 25 Jan 2021 11:43:24 +0000 (UTC) Subject: Re: [PATCH v13 09/12] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap To: Muchun Song , corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, rdunlap@infradead.org, oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, almasrymina@google.com, rientjes@google.com, willy@infradead.org, osalvador@suse.de, mhocko@suse.com, song.bao.hua@hisilicon.com, naoya.horiguchi@nec.com Cc: duanxiongchun@bytedance.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org References: <20210117151053.24600-1-songmuchun@bytedance.com> <20210117151053.24600-10-songmuchun@bytedance.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <7550ebba-fdb5-0dc9-a517-dda56bd105d9@redhat.com> Date: Mon, 25 Jan 2021 12:43:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210117151053.24600-10-songmuchun@bytedance.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.01.21 16:10, Muchun Song wrote: > Add a kernel parameter hugetlb_free_vmemmap to enable the feature of > freeing unused vmemmap pages associated with each hugetlb page on boot. The description completely lacks a description of the changes performed in arch/x86/mm/init_64.c. [...] > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1557,7 +1558,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > { > int err; > > - if (end - start < PAGES_PER_SECTION * sizeof(struct page)) > + if (is_hugetlb_free_vmemmap_enabled() || > + end - start < PAGES_PER_SECTION * sizeof(struct page)) This looks irresponsible. You ignore any altmap, even though current altmap users (ZONE_DEVICE) will not actually result in applicable vmemmaps that huge pages could ever use. Why do you ignore the altmap completely? This has to be properly documented, but IMHO it's not even the right approach to mess with altmap here. -- Thanks, David / dhildenb