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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 379B9C433F5 for ; Mon, 4 Apr 2022 12:02:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BC466B0072; Mon, 4 Apr 2022 08:02:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 745AD6B0073; Mon, 4 Apr 2022 08:02:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BE356B0074; Mon, 4 Apr 2022 08:02:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 460DD6B0072 for ; Mon, 4 Apr 2022 08:02:12 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 06C0A6144B for ; Mon, 4 Apr 2022 12:02:02 +0000 (UTC) X-FDA: 79319058084.15.138189D Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf29.hostedemail.com (Postfix) with ESMTP id 0FAA5120028 for ; Mon, 4 Apr 2022 12:01:57 +0000 (UTC) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-2eb888cf7e7so8147257b3.13 for ; Mon, 04 Apr 2022 05:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qiD2DiGzP9w26sYqe+Qe9/hDnbh5oNwQt5iQwmO4JSw=; b=f0Q/WVKIXSIDfrftxANHLkiSt8cLGcIxC2CKNOOHR1qG5zVRc6lm6AKe9sz79acMOl o2eMNhB+4khUHjghxea1XC3y2YB/ZKAHo4/aJv2HQQ9m83CByvZyEP3G64oxzlG0vO8F 8/8Ni0EIF6svCJYvrABjqP3Mq8lJdQZyK7M9voCo8A2QF5/wy7cXX6n689kSTuEHQdsy uWkaq+Px33gmCtC/pZB7GE7Qf+EoxpvqsZfCo1fEZiBVFvFKk/CQ76EHwjgohkYr2HIs df/HzJZ3KqkcSOVJP+cMXxOA9vRoUvH+IybMVW0g+ol8aymnpDd2O6/4MFMaaEG5q/rP gSSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qiD2DiGzP9w26sYqe+Qe9/hDnbh5oNwQt5iQwmO4JSw=; b=ikPW2K4fKte5kUCasTOdMa3S52uo8l8hyLAdkNJm5uci5px6B2WqiDjTUURZLdD6JD gf7nwml4Dyp3qlQAVstO1HZWxjsIWntMcQ4vZiHnHbq2hV/XV7dJvlIGaAinYLrlVaN5 Qsop4cHUZtN9foS4z3t8bvRt8NED0qCNS7XgT74vm6RKeaI2IHq1lx1ey28atQkecm2z lMxKsgQqUmsmOSlnSiPQ7wdXSkvn9NLzrNRhG/yoGDhfGQ5DyIJ9JYiT3pyPXs692tjl 4FuE1zbocXS85etpD6i+BWd8Gltnhs6CHlZtDQGJQUbuzGo+/AsFKjwqpa7pZ09rP3xm KXoQ== X-Gm-Message-State: AOAM5311Jx2kGnoR6TjE2iPNEABrmht6UOKQfDxpSP2TuFhjRmLDOi5r Jipsk7NMBBAHYv6v1GA0a4vwpKvUjxkF9ozTNfIsQA== X-Google-Smtp-Source: ABdhPJzlpsN0VsnXmKmAJkc1075L7eWicj13X0fkmppuQ3CoZUy2le5DGuweiF9leR/SLew6G9M1rG+BHnj3ZDFxaTU= X-Received: by 2002:a81:1196:0:b0:2eb:897a:7b5 with SMTP id 144-20020a811196000000b002eb897a07b5mr868948ywr.31.1649073716376; Mon, 04 Apr 2022 05:01:56 -0700 (PDT) MIME-Version: 1.0 References: <20220331065640.5777-1-songmuchun@bytedance.com> <20220331065640.5777-2-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Mon, 4 Apr 2022 20:01:20 +0800 Message-ID: Subject: Re: [PATCH v4 2/2] arm64: mm: hugetlb: Enable HUGETLB_PAGE_FREE_VMEMMAP for arm64 To: Anshuman Khandual Cc: Will Deacon , Andrew Morton , David Hildenbrand , "Bodeddula, Balasubramaniam" , Oscar Salvador , Mike Kravetz , David Rientjes , Mark Rutland , Catalin Marinas , james.morse@arm.com, Barry Song <21cnbao@gmail.com>, LAK , LKML , Linux Memory Management List , Xiongchun duan , Fam Zheng , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: hhqrjusek1adeho1kwcr88kj4z5e1yj6 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="f0Q/WVKI"; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf29.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspamd-Queue-Id: 0FAA5120028 X-HE-Tag: 1649073717-857557 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, Apr 4, 2022 at 5:25 PM Anshuman Khandual wrote: > > Hello Muchun, > > On 3/31/22 12:26, Muchun Song wrote: > > The feature of minimizing overhead of struct page associated with each > > HugeTLB page aims to free its vmemmap pages (used as struct page) to > > save memory, where is ~14GB/16GB per 1TB HugeTLB pages (2MB/1GB type). > > Enabling this feature saves us around 1.4/1.6 % memory but looking from > other way around, unavailability of vmemmap backing pages (~1.4GB) when > freeing up a corresponding HugeTLB page, could prevent ~1TB memory from > being used as normal page form (requiring their own struct pages), thus > forcing the HugeTLB page to remain as such ? Is not this problematic ? > > These additional 1TB memory in normal pages, from a HugeTLB dissolution > could have eased the system's memory pressure without this feature being > enabled. You are right. If the system is already under heavy memory pressure, it could prevent the user from freeing HugeTLB pages to the buddy allocator. If the HugeTLB page are allocated from non-movable zone, this scenario may be not problematic since once a HugeTLB page is freed, then the system will have memory to be allocated to be used as vmemmap pages, subsequent freeing of HugeTLB pages may be getting easier. However, if the HUgeTLB pages are allocated from the movable zone, then the thing becomes terrible, which is documented in Documentation/admin-guide/mm/memory-hotplug.rst. So there is a cmdline "hugetlb_free_vmemmap" to control if enabling this feature. The user should enable/disable this depending on their workload. Thanks.