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

On Thu 04-04-24 21:33:57, David Hildenbrand 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.

Completely agreed! It would be really great if Yang Shi could open the
topic with high level data and then we spent majority of the slot on the
actual discussion.

Thanks!
-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2024-04-30 14: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
2024-04-09 18:44         ` David Hildenbrand
2024-04-30 14:41       ` Michal Hocko [this message]
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=ZjEDGkg4AifZGQjv@tiehlicka \
    --to=mhocko@suse.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=olivier.singla@amperecomputing.com \
    --cc=shy828301@gmail.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