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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,NICE_REPLY_A,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 74911C433DB for ; Tue, 26 Jan 2021 09:36:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F3B97221EB for ; Tue, 26 Jan 2021 09:36:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3B97221EB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E4CC8D00B7; Tue, 26 Jan 2021 04:36:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 195328D00B0; Tue, 26 Jan 2021 04:36:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05CD98D00B7; Tue, 26 Jan 2021 04:36:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id E113E8D00B0 for ; Tue, 26 Jan 2021 04:36:39 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 941AC18041E6E for ; Tue, 26 Jan 2021 09:36:39 +0000 (UTC) X-FDA: 77747421318.30.cat17_6205b362758d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 5CBE018025887 for ; Tue, 26 Jan 2021 09:36:39 +0000 (UTC) X-HE-Tag: cat17_6205b362758d X-Filterd-Recvd-Size: 4650 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Jan 2021 09:36:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611653798; 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=oNqVieVd9v1G344GzpIPbD3/DSjB6v+2rop/NW6XtKU=; b=jWgEgYRS0do66jwS4NDu7kPLuYU+H/nclzZLUkUU3h3zh1no62B0lRo+vAU3jQO+/UYj+s 0o+Uba72FnhbRfMazBINNC2CUijNrYh3PkMVbMvhdY6s+qo88149afmu0qdvvviDvtA2Sp s1I2GRv3dBj72r1vteakUY/Y4fV7+tM= 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-440-U-Izs0d0Oeif6_p39Ww8hw-1; Tue, 26 Jan 2021 04:36:33 -0500 X-MC-Unique: U-Izs0d0Oeif6_p39Ww8hw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7BD021005504; Tue, 26 Jan 2021 09:36:29 +0000 (UTC) Received: from [10.36.114.192] (ovpn-114-192.ams2.redhat.com [10.36.114.192]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1481D60871; Tue, 26 Jan 2021 09:36:21 +0000 (UTC) Subject: Re: [PATCH v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page To: Oscar Salvador , Muchun Song Cc: 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, mhocko@suse.com, song.bao.hua@hisilicon.com, naoya.horiguchi@nec.com, 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-6-songmuchun@bytedance.com> <20210126092942.GA10602@linux> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <6fe52a7e-ebd8-f5ce-1fcd-5ed6896d3797@redhat.com> Date: Tue, 26 Jan 2021 10:36:21 +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: <20210126092942.GA10602@linux> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.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 26.01.21 10:29, Oscar Salvador wrote: > On Sun, Jan 17, 2021 at 11:10:46PM +0800, Muchun Song wrote: >> When we free a HugeTLB page to the buddy allocator, we should allocate the >> vmemmap pages associated with it. We can do that in the __free_hugepage() >> before freeing it to buddy. >> >> Signed-off-by: Muchun Song > > This series has grown a certain grade of madurity and improvment, but it seems > to me that we have been stuck in this patch (and patch#4) for quite some time. > > Would it be acceptable for a first implementation to not let hugetlb pages to > be freed when this feature is in use? > This would simplify things for now, as we could get rid of patch#4 and patch#5. > We can always extend functionality once this has been merged, right? I think either keep it completely simple (only free vmemmap of hugetlb pages allocated early during boot - which is what's not sufficient for some use cases) or implement the full thing properly (meaning, solve most challenging issues to get the basics running). I don't want to have some easy parts of complex features merged (e.g., breaking other stuff as you indicate below), and later finding out "it's not that easy" again and being stuck with it forever. > > Of course, this means that e.g: memory-hotplug (hot-remove) will not fully work > when this in place, but well. Can you elaborate? Are we're talking about having hugepages in ZONE_MOVABLE that are not migratable (and/or dissolvable) anymore? Than a clear NACK from my side. -- Thanks, David / dhildenb