All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Muchun Song <songmuchun@bytedance.com>,
	will@kernel.org, akpm@linux-foundation.org, david@redhat.com,
	bodeddub@amazon.com, osalvador@suse.de, mike.kravetz@oracle.com,
	rientjes@google.com, mark.rutland@arm.com,
	catalin.marinas@arm.com, james.morse@arm.com, 21cnbao@gmail.com
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	duanxiongchun@bytedance.com, fam.zheng@bytedance.com,
	smuchun@gmail.com
Subject: Re: [PATCH v4 2/2] arm64: mm: hugetlb: Enable HUGETLB_PAGE_FREE_VMEMMAP for arm64
Date: Mon, 4 Apr 2022 14:56:17 +0530	[thread overview]
Message-ID: <dd980687-a1ef-f4b5-bb29-da14f89c087e@arm.com> (raw)
In-Reply-To: <20220331065640.5777-2-songmuchun@bytedance.com>

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.

- Anshuman

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Muchun Song <songmuchun@bytedance.com>,
	will@kernel.org, akpm@linux-foundation.org, david@redhat.com,
	bodeddub@amazon.com, osalvador@suse.de, mike.kravetz@oracle.com,
	rientjes@google.com, mark.rutland@arm.com,
	catalin.marinas@arm.com, james.morse@arm.com, 21cnbao@gmail.com
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	duanxiongchun@bytedance.com, fam.zheng@bytedance.com,
	smuchun@gmail.com
Subject: Re: [PATCH v4 2/2] arm64: mm: hugetlb: Enable HUGETLB_PAGE_FREE_VMEMMAP for arm64
Date: Mon, 4 Apr 2022 14:56:17 +0530	[thread overview]
Message-ID: <dd980687-a1ef-f4b5-bb29-da14f89c087e@arm.com> (raw)
In-Reply-To: <20220331065640.5777-2-songmuchun@bytedance.com>

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.

- Anshuman

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-04-04  9:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  6:56 [PATCH v4 1/2] mm: hugetlb_vmemmap: introduce ARCH_WANT_HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2022-03-31  6:56 ` Muchun Song
2022-03-31  6:56 ` [PATCH v4 2/2] arm64: mm: hugetlb: Enable HUGETLB_PAGE_FREE_VMEMMAP for arm64 Muchun Song
2022-03-31  6:56   ` Muchun Song
2022-03-31 22:31   ` Barry Song
2022-03-31 22:31     ` Barry Song
2022-04-04  9:26   ` Anshuman Khandual [this message]
2022-04-04  9:26     ` Anshuman Khandual
2022-04-04 12:01     ` Muchun Song
2022-04-04 12:01       ` Muchun Song
2022-04-05  3:34       ` Anshuman Khandual
2022-04-05  3:34         ` Anshuman Khandual
2022-04-05  3:49         ` Muchun Song
2022-04-05  3:49           ` Muchun Song
2022-04-05  4:45   ` Anshuman Khandual
2022-04-05  4:45     ` Anshuman Khandual
2022-04-05  8:38     ` Muchun Song
2022-04-05  8:38       ` Muchun Song
2022-04-11  9:17       ` Anshuman Khandual
2022-04-11  9:17         ` Anshuman Khandual
2022-04-11 10:40         ` Muchun Song
2022-04-11 10:40           ` Muchun Song
2022-04-11 10:12   ` Anshuman Khandual
2022-04-11 10:12     ` Anshuman Khandual
2022-04-11 11:55     ` Muchun Song
2022-04-11 11:55       ` Muchun Song
2022-04-13 10:33   ` Anshuman Khandual
2022-04-13 10:33     ` Anshuman Khandual
2022-04-13 14:59     ` Muchun Song
2022-04-13 14:59       ` Muchun Song
2022-03-31  8:42 ` [PATCH v4 1/2] mm: hugetlb_vmemmap: introduce ARCH_WANT_HUGETLB_PAGE_FREE_VMEMMAP David Hildenbrand
2022-03-31  8:42   ` David Hildenbrand
2022-03-31  8:48   ` Muchun Song
2022-03-31  8:48     ` Muchun Song
2022-03-31  8:50     ` David Hildenbrand
2022-03-31  8:50       ` David Hildenbrand
2022-03-31  8:53       ` Muchun Song
2022-03-31  8:53         ` Muchun Song
2022-03-31 22:19 ` Barry Song
2022-03-31 22:19   ` Barry Song
2022-04-04  9:05 ` Anshuman Khandual
2022-04-04  9:05   ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd980687-a1ef-f4b5-bb29-da14f89c087e@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bodeddub@amazon.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=fam.zheng@bytedance.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.kravetz@oracle.com \
    --cc=osalvador@suse.de \
    --cc=rientjes@google.com \
    --cc=smuchun@gmail.com \
    --cc=songmuchun@bytedance.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.