All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: 黄杰 <huangjie.albert@bytedance.com>,
	songmuchun@bytedance.com,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH] mm: hugetlb: support get/set_policy for hugetlb_vm_ops
Date: Mon, 17 Oct 2022 10:59:31 -0700	[thread overview]
Message-ID: <Y02YAyE1TnU6/dkA@monkey> (raw)
In-Reply-To: <2f41fc4c-68eb-ab7d-970b-fcb10f474fd4@redhat.com>

On 10/17/22 13:33, David Hildenbrand wrote:
> On 17.10.22 11:48, 黄杰 wrote:
> > David Hildenbrand <david@redhat.com> 于2022年10月17日周一 16:44写道:
> > > 
> > > On 12.10.22 10:15, Albert Huang wrote:
> > > > From: "huangjie.albert" <huangjie.albert@bytedance.com>
> > > > 
> > > > implement these two functions so that we can set the mempolicy to
> > > > the inode of the hugetlb file. This ensures that the mempolicy of
> > > > all processes sharing this huge page file is consistent.
> > > > 
> > > > In some scenarios where huge pages are shared:
> > > > if we need to limit the memory usage of vm within node0, so I set qemu's
> > > > mempilciy bind to node0, but if there is a process (such as virtiofsd)
> > > > shared memory with the vm, in this case. If the page fault is triggered
> > > > by virtiofsd, the allocated memory may go to node1 which  depends on
> > > > virtiofsd.
> > > > 
> > > 
> > > Any VM that uses hugetlb should be preallocating memory. For example,
> > > this is the expected default under QEMU when using huge pages.
> > > 
> > > Once preallocation does the right thing regarding NUMA policy, there is
> > > no need to worry about it in other sub-processes.
> > > 
> > 
> > Hi, David
> > thanks for your reminder
> > 
> > Yes, you are absolutely right, However, the pre-allocation mechanism
> > does solve this problem.
> > However, some scenarios do not like to use the pre-allocation mechanism, such as
> > scenarios that are sensitive to virtual machine startup time, or
> > scenarios that require
> > high memory utilization. The on-demand allocation mechanism may be better,
> > so the key point is to find a way support for shared policy。
> 
> Using hugetlb -- with a fixed pool size -- without preallocation is like
> playing with fire. Hugetlb reservation makes one believe that on-demand
> allocation is going to work, but there are various scenarios where that can
> go seriously wrong, and you can run out of huge pages.

I absolutely agree with this cautionary note.

hugetlb reservations guarantee that a sufficient number of huge pages exist.
However, there is no guarantee that those pages are on any specific node
associated with a numa policy.  Therefore, an 'on demand' allocation could
fail resulting in SIGBUS being set to the faulting process.
-- 
Mike Kravetz


  parent reply	other threads:[~2022-10-17 17:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12  8:15 [PATCH] mm: hugetlb: support get/set_policy for hugetlb_vm_ops Albert Huang
2022-10-12 19:45 ` Hugh Dickins
2022-10-14 16:56   ` Mike Kravetz
2022-10-17  3:35     ` [External] " 黄杰
2022-10-19  9:29     ` [PATCH v2] mm: hugetlb: support for shared memory policy Albert Huang
2022-10-19 11:49       ` Aneesh Kumar K V
2022-10-19  9:33   ` [PATCH] mm: hugetlb: support get/set_policy for hugetlb_vm_ops 黄杰
2022-10-23 20:16     ` Hugh Dickins
2022-10-17  8:44 ` David Hildenbrand
2022-10-17  9:48   ` [External] " 黄杰
2022-10-17 11:33     ` David Hildenbrand
2022-10-17 11:46       ` 黄杰
2022-10-17 12:00         ` David Hildenbrand
2022-10-18  9:27           ` 黄杰
2022-10-18  9:35             ` David Hildenbrand
2022-10-17 17:59       ` Mike Kravetz [this message]
2022-10-18  9:24         ` 黄杰

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=Y02YAyE1TnU6/dkA@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=huangjie.albert@bytedance.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=songmuchun@bytedance.com \
    /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.