linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Christoph Lameter (Ampere)" <cl@linux.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	 lsf-pc@lists.linux-foundation.org,
	olivier.singla@amperecomputing.com,
	 Linux MM <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.com>,
	 Dan Williams <dan.j.williams@intel.com>
Subject: Re: [LSF/MM/BPF TOPIC] Multi-sized THP performance benchmarks and analysis on ARM64
Date: Tue, 9 Apr 2024 11:41:19 -0700	[thread overview]
Message-ID: <CAHbLzkqWL_BF26kdPn1p+UOeb4ZD8rn-iz7DQF5RUzaqgUru=A@mail.gmail.com> (raw)
In-Reply-To: <9b3c2d48-96f2-4d29-b2ba-a0f2ea47da45@redhat.com>

On Thu, Apr 4, 2024 at 12:34 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 04.04.24 20:57, Christoph Lameter (Ampere) wrote:
> > On Mon, 1 Apr 2024, Jonathan Cameron wrote:
> >
> >> Sounds like useful data, but is it a suitable topic for LSF-MM?
> >> What open questions etc is it raising?
> >
> >
> > mTHP is new functionality that will require additional work to support
> > more use cases. It is also unclear at this point in what usecases mTHP is
> > useful and where no benefit can so far be seen. Also the effect of
> > coalescing multiple PTE entries into one TLB entry is new to MM
> > (CONT_PTE).
> >
> > Ultimately it would be useful to have mTHP support also provide larger
> > blocksize capabilities for filesystem etc etc. mTHP needs to mature and an
> > analysis of the arguable a bit experimental state of affairs can help a
> > lot in getting there.
>
> Right, something like that (open items, missed use cases, requirements,
> ideas, etc,.) would be a better (good!) fit.
>
> Pure benchmark results, analysis and recommendations are great. But
> likely a better fit for a (white) paper, blog post,
> less-discussion-focused conference.

Thanks for the suggestion. I didn't plan to enumerate any open items
because I think those items (for example, khugepaged support, swap,
etc) were already well-known by mm community and we have made some
progress on some items.

The potential future optimization choices led by the benchmark and
analysis may be worth discussing. For example, shall the allocation
fallback should try every single order, is it a good idea to let users
decide the orders, etc. We didn't know what the good choice should be
before we had some benchmark data.

>
> --
> Cheers,
>
> David / dhildenb
>


  reply	other threads:[~2024-04-09 18:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 16:47 Yang Shi
2024-04-01 18:16 ` Jonathan Cameron
2024-04-02 20:04   ` Yang Shi
2024-04-04 18:57   ` Christoph Lameter (Ampere)
2024-04-04 19:33     ` David Hildenbrand
2024-04-09 18:41       ` Yang Shi [this message]
2024-04-09 18:44         ` David Hildenbrand
2024-04-30 14:41       ` Michal Hocko
2024-05-01 16:37         ` Yang Shi
2024-04-08 16:30     ` Matthew Wilcox
2024-04-08 18:56       ` Zi Yan
2024-04-09 10:47         ` Ryan Roberts
2024-06-25 11:12           ` Ryan Roberts
2024-06-25 18:11             ` Christoph Lameter (Ampere)
2024-06-26 10:47               ` Ryan Roberts
2024-06-27 20:54             ` Yang Shi

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='CAHbLzkqWL_BF26kdPn1p+UOeb4ZD8rn-iz7DQF5RUzaqgUru=A@mail.gmail.com' \
    --to=shy828301@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=cl@linux.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@suse.com \
    --cc=olivier.singla@amperecomputing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox