All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: SeongJae Park <sj@kernel.org>,
	"Liam R. Howlett" <howlett@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Vlastimil Babka <vbabka@suse.cz>,
	kernel-team@meta.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 0/9] mm/madvise: batch tlb flushes for MADV_DONTNEED and MADV_FREE
Date: Mon, 10 Mar 2025 16:27:10 -0700	[thread overview]
Message-ID: <20250310232710.74733-1-sj@kernel.org> (raw)
In-Reply-To: <20250310153921.47d390c637105e3ad6fc49c0@linux-foundation.org>

On Mon, 10 Mar 2025 15:39:21 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 10 Mar 2025 10:23:09 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> >  It is unclear if such use case
> > is common and the inefficiency is significant. 
> 
> Well, we could conduct a survey,
> 
> Can you add some logging to detect when userspace performs such an
> madvise() call, then run that kernel on some "typical" machines which
> are running "typical" workloads?  That should give us a feeling for how
> often userspace does this,

I agree that could make this patch series more informative.

> and hence will help us understand the usefulness
> of this patchset.

Nevertheless, what this patchset is really trying to optimize is not the
madvise() use case, but process_madvise() use.  I believe the usage is
apparently common, given the vectorization based semantic of process_madvise().
Jemalloc is also adding[1] that kind of use case.  And the benefit is clear,
given the microbenchmark results that I shared.

Also, this patchset shouldn't introduce new regression to madvise().

Hence, I think the survey can be interestign and helpful, but shouldn't be a
blocker for this patch series.  Coudl you please let me know if I'm missing
something and if you still want the survey?

[1] https://github.com/jemalloc/jemalloc/pull/2794


Thanks,
SJ


  parent reply	other threads:[~2025-03-10 23:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 17:23 [PATCH 0/9] mm/madvise: batch tlb flushes for MADV_DONTNEED and MADV_FREE SeongJae Park
2025-03-10 17:23 ` [PATCH 1/9] mm/madvise: use is_memory_failure() from madvise_do_behavior() SeongJae Park
2025-03-11 11:27   ` Lorenzo Stoakes
2025-03-10 17:23 ` [PATCH 2/9] mm/madvise: split out populate behavior check logic SeongJae Park
2025-03-11 11:29   ` Lorenzo Stoakes
2025-03-10 17:23 ` [PATCH 3/9] mm/madvise: deduplicate madvise_do_behavior() skip case handlings SeongJae Park
2025-03-11 12:02   ` Lorenzo Stoakes
2025-03-11 20:54     ` SeongJae Park
2025-03-10 17:23 ` [PATCH 4/9] mm/madvise: remove len parameter of madvise_do_behavior() SeongJae Park
2025-03-11 12:05   ` Lorenzo Stoakes
2025-03-10 17:23 ` [PATCH 5/9] mm/madvise: define and use madvise_behavior struct for madvise_do_behavior() SeongJae Park
2025-03-11 12:17   ` Lorenzo Stoakes
2025-03-11 20:56     ` SeongJae Park
2025-03-12  5:47       ` Lorenzo Stoakes
2025-03-12 17:23         ` SeongJae Park
2025-03-10 17:23 ` [PATCH 6/9] mm/memory: split non-tlb flushing part from zap_page_range_single() SeongJae Park
2025-03-11 12:45   ` Lorenzo Stoakes
2025-03-11 20:58     ` SeongJae Park
2025-03-31 20:24       ` SeongJae Park
2025-04-01  1:45   ` Liam R. Howlett
2025-04-01  2:48     ` SeongJae Park
2025-04-01 14:03       ` Liam R. Howlett
2025-04-01 21:25         ` SeongJae Park
2025-03-10 17:23 ` [PATCH 7/9] mm/madvise: let madvise_{dontneed,free}_single_vma() caller batches tlb flushes SeongJae Park
2025-03-11 13:07   ` Lorenzo Stoakes
2025-03-11 21:00     ` SeongJae Park
2025-03-10 17:23 ` [PATCH 8/9] mm/madvise: batch tlb flushes for [process_]madvise(MADV_{DONTNEED[_LOCKED],FREE}) SeongJae Park
2025-03-11 13:59   ` Lorenzo Stoakes
2025-03-11 21:01     ` SeongJae Park
2025-04-01 21:17   ` SeongJae Park
2025-03-10 17:23 ` [PATCH 9/9] mm/madvise: remove !tlb support from madvise_{dontneed,free}_single_vma() SeongJae Park
2025-03-11 14:01   ` Lorenzo Stoakes
2025-03-11 21:02     ` SeongJae Park
2025-03-12 13:46       ` Lorenzo Stoakes
2025-04-01 21:22         ` SeongJae Park
2025-03-10 22:39 ` [PATCH 0/9] mm/madvise: batch tlb flushes for MADV_DONTNEED and MADV_FREE Andrew Morton
2025-03-10 23:15   ` Shakeel Butt
2025-03-10 23:36     ` Roman Gushchin
2025-03-11 11:17       ` Lorenzo Stoakes
2025-03-10 23:27   ` SeongJae Park [this message]
2025-03-11 12:49 ` Lorenzo Stoakes
2025-03-11 21:03   ` SeongJae Park

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=20250310232710.74733-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=howlett@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=shakeel.butt@linux.dev \
    --cc=vbabka@suse.cz \
    /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.