Received-SPF: pass (google.com: domain of linux-kernel+bounces-102640-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 13 Mar 2024 16:32:52 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
To: Will Deacon <will@kernel.org>
cc: Nanyong Sun <sunnanyong@huawei.com>, 
    Catalin Marinas <catalin.marinas@arm.com>, 
    Matthew Wilcox <willy@infradead.org>, muchun.song@linux.dev, 
    Andrew Morton <akpm@linux-foundation.org>, anshuman.khandual@arm.com, 
    wangkefeng.wang@huawei.com, linux-arm-kernel@lists.infradead.org, 
    linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
    Yu Zhao <yuzhao@google.com>, Yosry Ahmed <yosryahmed@google.com>, 
    Sourav Panda <souravpanda@google.com>
Subject: Re: [PATCH v3 0/3] A Solution to Re-enable hugetlb vmemmap
 optimize
In-Reply-To: <20240208131734.GA23428@willie-the-truck>
Message-ID: <f8a643a9-4932-9ba4-94f1-4bc88ee27740@google.com>
References: <20240113094436.2506396-1-sunnanyong@huawei.com> <ZbKjHHeEdFYY1xR5@arm.com> <d1671959-74a4-8ea5-81f0-539df8d9c0f0@huawei.com> <20240207111252.GA22167@willie-the-truck> <ZcNnrdlb3fe0kGHK@casper.infradead.org> <ZcN1hTrAhy-B1P2_@arm.com>
 <44075bc2-ac5f-ffcd-0d2f-4093351a6151@huawei.com> <20240208131734.GA23428@willie-the-truck>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="2003064516-144154717-1710372487=:1424452"
Content-ID: <35d77e60-41b9-7263-4bd3-47f07a148a86@google.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--2003064516-144154717-1710372487=:1424452
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <9e36df0a-b6e1-52a5-34af-6b5859d9248f@google.com>

On Thu, 8 Feb 2024, Will Deacon wrote:

> > How about take a new lock with irq disabled during BBM, like:
> > 
> > +void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte)
> > +{
> > +    spin_lock_irq(NEW_LOCK);
> > +    pte_clear(&init_mm, addr, ptep);
> > +    flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> > +    set_pte_at(&init_mm, addr, ptep, pte);
> > +    spin_unlock_irq(NEW_LOCK);
> > +}
> 
> I really think the only maintainable way to achieve this is to avoid the
> possibility of a fault altogether.
> 
> Will
> 
> 

Nanyong, are you still actively working on making HVO possible on arm64?

This would yield a substantial memory savings on hosts that are largely 
configured with hugetlbfs.  In our case, the size of this hugetlbfs pool 
is actually never changed after boot, but it sounds from the thread that 
there was an idea to make HVO conditional on FEAT_BBM.  Is this being 
pursued?

If so, any testing help needed?
--2003064516-144154717-1710372487=:1424452--