linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Kalesh Singh <kaleshsingh@google.com>,
	minchan@kernel.org, Liam.Howlett@oracle.com, rppt@kernel.org,
	pfalcato@suse.de, kernel-team@android.com, android-mm@google.com,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Kees Cook <kees@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Jann Horn <jannh@google.com>, Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 0/7] vma count: fixes, test and improvements
Date: Thu, 18 Sep 2025 13:49:33 +0100	[thread overview]
Message-ID: <7e3de8d3-c064-4ef4-85f8-48294a238336@lucifer.local> (raw)
In-Reply-To: <0c068e35-0954-43fd-b3b3-20786a6a12fe@redhat.com>

On Thu, Sep 18, 2025 at 02:07:09PM +0200, David Hildenbrand wrote:
> On 18.09.25 12:29, Lorenzo Stoakes wrote:
> > On Wed, Sep 17, 2025 at 04:32:31PM -0700, Andrew Morton wrote:
> > > On Wed, 17 Sep 2025 06:36:34 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > >
> > > > >
> > > > > > Perhaps being less accepting of patches during merge window is one aspect,
> > > > > > as the merge window leading up to this cycle was almost the same review
> > > > > > load as when the cycle started.
> > > > >
> > > > > I'm having trouble understanding what you said here?
> > > >
> > > > Sorry, what I mean to say is that in mm we're pretty open to taking stuff in the
> > > > merge window, esp. now we have mm-new.
> > > >
> > > > And last merge window my review load felt similar to during a cycle, which
> > > > was kind of crazy.
> > > >
> > > > So I wonder if we should be less accommodating and simply say 'sorry it's
> > > > the merge window, no submissions accepted'?
> > >
> > > hm, I always have a lot of emails piled up by the time mm-stable gets
> > > merged upstream.  That ~1 week between "we merged" and "-rc1" is a nice
> > > time to go through that material and add it to mm-new.  I think it
> > > smooths things out.  I mean, this is peak time for people to be
> > > considering the new material?
> >
> > I'm confused, why is the merge window a good time to consider new material?
> >
> > People have the entirety of the cycle to submit new material, and they do
> > so.
>
> My view is that if you are sending a cleanup/feature during the merge window
> you cannot expect a fast reply, and you should not keep sending new versions
> in that timeframe expecting that all people you CCed that should have a look
> actually did have a look.

Yes exactly.

The problem is all the conversations and respins and etc. _do_ carry on as
normal, and often land in mm-new, queued up for mm-unstable etc. unless we
happen to notice them.

So it makes it impossible for us to just ignore until the next cycle (or need to
go through every thread that happened afterwards).

And people know that, so just keep on submitting as normal. That was _really_
palpable last merge window.

I mean I'm cheating by going on vacation for this merge window ;) but obviously
means I'll have 2 weeks of review to check when I get back + 1st week of cycle
to go too.

I think in some subsystems new series/respins are actively unwelcome during the
merge window. I wonder if we should be the same?

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

Cheers, Lorenzo


  reply	other threads:[~2025-09-18 12:49 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 16:36 Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 1/7] mm: fix off-by-one error in VMA count limit checks Kalesh Singh
2025-09-15 22:36   ` Andrew Morton
2025-09-16 14:20     ` Jonathan Corbet
2025-09-17  1:16       ` Andrew Morton
2025-09-16  9:45   ` Pedro Falcato
2025-09-17  7:44   ` SeongJae Park
2025-09-17 10:52   ` David Hildenbrand
2025-09-18 11:31   ` Pedro Falcato
2025-09-18 13:53   ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 2/7] mm/selftests: add max_vma_count tests Kalesh Singh
2025-09-17 10:58   ` David Hildenbrand
2025-09-17 16:49     ` Kalesh Singh
2025-09-18 14:42   ` Lorenzo Stoakes
2025-09-18 16:21     ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 3/7] mm: introduce vma_count_remaining() Kalesh Singh
2025-09-17 13:38   ` David Hildenbrand
2025-09-17 17:10     ` Kalesh Singh
2025-09-18 13:20   ` Lorenzo Stoakes
2025-09-18 13:26     ` Lorenzo Stoakes
2025-09-18 14:31   ` Lorenzo Stoakes
2025-09-18 15:52     ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 4/7] mm: rename mm_struct::map_count to vma_count Kalesh Singh
2025-09-17 13:41   ` David Hildenbrand
2025-09-18 11:46   ` Pedro Falcato
2025-09-18 14:48   ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 5/7] mm: harden vma_count against direct modification Kalesh Singh
2025-09-18 14:52   ` Lorenzo Stoakes
2025-09-18 15:43     ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 6/7] mm: add assertion for VMA count limit Kalesh Singh
2025-09-17 13:44   ` David Hildenbrand
2025-09-17 17:22     ` Kalesh Singh
2025-09-17 18:34       ` David Hildenbrand
2025-09-17 20:31         ` Kalesh Singh
2025-09-18 11:48     ` Pedro Falcato
2025-09-18 13:30   ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 7/7] mm/tracing: introduce max_vma_count_exceeded trace event Kalesh Singh
2025-09-15 23:41   ` Steven Rostedt
2025-09-16  1:19     ` Kalesh Singh
2025-09-16 15:52       ` Steven Rostedt
2025-09-16 17:36         ` Kalesh Singh
2025-09-16 17:48           ` Steven Rostedt
2025-09-16 17:57             ` Kalesh Singh
2025-09-16 18:02               ` Steven Rostedt
2025-09-16 18:23                 ` Kalesh Singh
2025-09-16 18:51                   ` Steven Rostedt
2025-09-16 20:08                     ` Kalesh Singh
2025-09-18 11:38         ` Pedro Falcato
2025-09-18 14:48           ` Steven Rostedt
2025-09-18 13:42   ` Lorenzo Stoakes
2025-09-18 13:51     ` Lorenzo Stoakes
2025-09-18 15:55       ` Kalesh Singh
2025-09-15 22:34 ` [PATCH v2 0/7] vma count: fixes, test and improvements Andrew Morton
2025-09-15 23:10   ` Kalesh Singh
2025-09-16  0:05     ` Andrew Morton
2025-09-16  1:23       ` Kalesh Singh
2025-09-16 10:12   ` Lorenzo Stoakes
2025-09-16 17:47     ` Kalesh Singh
2025-09-17  2:16     ` Andrew Morton
2025-09-17  5:36       ` Lorenzo Stoakes
2025-09-17 23:32         ` Andrew Morton
2025-09-18 10:29           ` Lorenzo Stoakes
2025-09-18 12:07             ` David Hildenbrand
2025-09-18 12:49               ` Lorenzo Stoakes [this message]
2025-09-18 20:59                 ` Andrew Morton

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=7e3de8d3-c064-4ef4-85f8-48294a238336@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=android-mm@google.com \
    --cc=brauner@kernel.org \
    --cc=bsegall@google.com \
    --cc=david@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kaleshsingh@google.com \
    --cc=kees@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mgorman@suse.de \
    --cc=mhiramat@kernel.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pfalcato@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vschneid@redhat.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