Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Usama Arif]

On 02/04/2026 19:08, Usama Arif wrote:
> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
>   to HPAGE_PMD_SIZE limited to 2M (Rui)
> - Reviewed-by tags for patch 1 from Kiryl and Jan
> - Remove preferred_exec_order() (Jan)
> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
>   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
>   do_sync_mmap_readahead().
> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
>   page size for arm64.
> - remove bprm->file NULL check (Matthew)
> - Change filp to file (Matthew)
> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> 

Hello!

Just wanted to check if there was any feedback/review on the latest
revision? 

Thanks!

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Lorenzo Stoakes]

On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
>
>
> On 02/04/2026 19:08, Usama Arif wrote:
> > v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> > - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> >   to HPAGE_PMD_SIZE limited to 2M (Rui)
> > - Reviewed-by tags for patch 1 from Kiryl and Jan
> > - Remove preferred_exec_order() (Jan)
> > - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> >   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> >   do_sync_mmap_readahead().
> > - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> >   page size for arm64.
> > - remove bprm->file NULL check (Matthew)
> > - Change filp to file (Matthew)
> > - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> >
>
> Hello!
>
> Just wanted to check if there was any feedback/review on the latest
> revision?

It's -rc7, this is definitely something for next cycle :)

On my part, my upstream bandwidth has drastically reduced, and review is
probably going to have to be a hobbyist thing at least for now.

Also, not to be mean but:

$ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
21

So... :)

Review in mm is very lop-sided, let's try to balance it out a bit!

>
> Thanks!
>

Thanks, Lorenzo

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Lorenzo Stoakes]

On Fri, Apr 10, 2026 at 12:55:42PM +0100, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
> >
> >
> > On 02/04/2026 19:08, Usama Arif wrote:
> > > v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> > > - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> > >   to HPAGE_PMD_SIZE limited to 2M (Rui)
> > > - Reviewed-by tags for patch 1 from Kiryl and Jan
> > > - Remove preferred_exec_order() (Jan)
> > > - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> > >   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> > >   do_sync_mmap_readahead().
> > > - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> > >   page size for arm64.
> > > - remove bprm->file NULL check (Matthew)
> > > - Change filp to file (Matthew)
> > > - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> > >
> >
> > Hello!
> >
> > Just wanted to check if there was any feedback/review on the latest
> > revision?
>
> It's -rc7, this is definitely something for next cycle :)
>
> On my part, my upstream bandwidth has drastically reduced, and review is
> probably going to have to be a hobbyist thing at least for now.
>
> Also, not to be mean but:
>
> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> 21
>
> So... :)
>
> Review in mm is very lop-sided, let's try to balance it out a bit!
>
> >
> > Thanks!
> >
>
> Thanks, Lorenzo

(Note that we're in a 'quiet period' from here until -rc1 of next cycle and
won't be taking anything new until then. We plan to do this from around rc5 or
rc6 of each cycle in future).

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Usama Arif]

On 10/04/2026 12:57, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 12:55:42PM +0100, Lorenzo Stoakes wrote:
>> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
>>>
>>>
>>> On 02/04/2026 19:08, Usama Arif wrote:
>>>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
>>>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
>>>>   to HPAGE_PMD_SIZE limited to 2M (Rui)
>>>> - Reviewed-by tags for patch 1 from Kiryl and Jan
>>>> - Remove preferred_exec_order() (Jan)
>>>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
>>>>   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
>>>>   do_sync_mmap_readahead().
>>>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
>>>>   page size for arm64.
>>>> - remove bprm->file NULL check (Matthew)
>>>> - Change filp to file (Matthew)
>>>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
>>>>
>>>
>>> Hello!
>>>
>>> Just wanted to check if there was any feedback/review on the latest
>>> revision?
>>
>> It's -rc7, this is definitely something for next cycle :)
>>
>> On my part, my upstream bandwidth has drastically reduced, and review is
>> probably going to have to be a hobbyist thing at least for now.
>>
>> Also, not to be mean but:
>>
>> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
>> 21
>>
>> So... :)
>>
>> Review in mm is very lop-sided, let's try to balance it out a bit!
>>
>>>
>>> Thanks!
>>>
>>
>> Thanks, Lorenzo
> 
> (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
> won't be taking anything new until then. We plan to do this from around rc5 or
> rc6 of each cycle in future).

Thanks! Just wanted to check, as I am always confused about this. Is it ok
to send patches for review for next release at this time? So that they
are in a good state when rc1 comes. I wanted to send PMD swap entries
for review after I am finished testing, but I want them for review for
next release.

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Lorenzo Stoakes]

On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
>
>
> On 10/04/2026 12:57, Lorenzo Stoakes wrote:
> > On Fri, Apr 10, 2026 at 12:55:42PM +0100, Lorenzo Stoakes wrote:
> >> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
> >>>
> >>>
> >>> On 02/04/2026 19:08, Usama Arif wrote:
> >>>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> >>>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> >>>>   to HPAGE_PMD_SIZE limited to 2M (Rui)
> >>>> - Reviewed-by tags for patch 1 from Kiryl and Jan
> >>>> - Remove preferred_exec_order() (Jan)
> >>>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> >>>>   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> >>>>   do_sync_mmap_readahead().
> >>>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> >>>>   page size for arm64.
> >>>> - remove bprm->file NULL check (Matthew)
> >>>> - Change filp to file (Matthew)
> >>>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> >>>>
> >>>
> >>> Hello!
> >>>
> >>> Just wanted to check if there was any feedback/review on the latest
> >>> revision?
> >>
> >> It's -rc7, this is definitely something for next cycle :)
> >>
> >> On my part, my upstream bandwidth has drastically reduced, and review is
> >> probably going to have to be a hobbyist thing at least for now.
> >>
> >> Also, not to be mean but:
> >>
> >> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> >> 21
> >>
> >> So... :)
> >>
> >> Review in mm is very lop-sided, let's try to balance it out a bit!
> >>
> >>>
> >>> Thanks!
> >>>
> >>
> >> Thanks, Lorenzo
> >
> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
> > won't be taking anything new until then. We plan to do this from around rc5 or
> > rc6 of each cycle in future).
>
> Thanks! Just wanted to check, as I am always confused about this. Is it ok
> to send patches for review for next release at this time? So that they
> are in a good state when rc1 comes. I wanted to send PMD swap entries
> for review after I am finished testing, but I want them for review for
> next release.

I think different people have different views on that :)

I mean it's debateable whether having a glut of new material on day one of -rc1
is preferable to having a bunch come in that might or might not get lost along
the way :)

I personally feel it'd be better to send during the cycle window rather than
before but I suspect others disagree with that!

So from your point of view, feel free to do what you like, but maybe David +
others would want to chime in with their opinions?

Thanks, Lorenzo

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Vlastimil Babka (SUSE)]

On 4/10/26 14:24, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
>> >> Thanks, Lorenzo
>> >
>> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
>> > won't be taking anything new until then. We plan to do this from around rc5 or
>> > rc6 of each cycle in future).
>>
>> Thanks! Just wanted to check, as I am always confused about this. Is it ok
>> to send patches for review for next release at this time? So that they
>> are in a good state when rc1 comes. I wanted to send PMD swap entries
>> for review after I am finished testing, but I want them for review for
>> next release.
> 
> I think different people have different views on that :)
> 
> I mean it's debateable whether having a glut of new material on day one of -rc1
> is preferable to having a bunch come in that might or might not get lost along
> the way :)
> 
> I personally feel it'd be better to send during the cycle window rather than
> before but I suspect others disagree with that!
> 
> So from your point of view, feel free to do what you like, but maybe David +
> others would want to chime in with their opinions?

For me the more important part of the quiet period is that patches can't be
merged, so there's less urgency to review them immediately. So I think it's
fine to still send patches, but not having expectations about quick
response, as people might be taking time off.

On the other hand it would be better if new series could mature in this
quiet period, so there would be less work after rc1. But the key to making
that possible I think is to feel less urgency/being overwhelmed also in the
non-quiet period (rc1-rc5/6). Then it's should be less necessary to take
time off during the quiet period. So hopefully we'll get there through
involving more reviewers, and by having more submaintainers agency.

Vlastimil

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Lorenzo Stoakes]

On Fri, Apr 10, 2026 at 03:29:12PM +0200, Vlastimil Babka (SUSE) wrote:
> On 4/10/26 14:24, Lorenzo Stoakes wrote:
> > On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
> >> >> Thanks, Lorenzo
> >> >
> >> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
> >> > won't be taking anything new until then. We plan to do this from around rc5 or
> >> > rc6 of each cycle in future).
> >>
> >> Thanks! Just wanted to check, as I am always confused about this. Is it ok
> >> to send patches for review for next release at this time? So that they
> >> are in a good state when rc1 comes. I wanted to send PMD swap entries
> >> for review after I am finished testing, but I want them for review for
> >> next release.
> >
> > I think different people have different views on that :)
> >
> > I mean it's debateable whether having a glut of new material on day one of -rc1
> > is preferable to having a bunch come in that might or might not get lost along
> > the way :)
> >
> > I personally feel it'd be better to send during the cycle window rather than
> > before but I suspect others disagree with that!
> >
> > So from your point of view, feel free to do what you like, but maybe David +
> > others would want to chime in with their opinions?
>
> For me the more important part of the quiet period is that patches can't be
> merged, so there's less urgency to review them immediately. So I think it's
> fine to still send patches, but not having expectations about quick
> response, as people might be taking time off.
>
> On the other hand it would be better if new series could mature in this
> quiet period, so there would be less work after rc1. But the key to making
> that possible I think is to feel less urgency/being overwhelmed also in the
> non-quiet period (rc1-rc5/6). Then it's should be less necessary to take
> time off during the quiet period. So hopefully we'll get there through
> involving more reviewers, and by having more submaintainers agency.

Yeah I sympathise with that.

But until we for-sure have <you know what :))> signoff, I worry about the risk
of series 'just being taken' at -rc1 because it maybe seems easier to do that,
and then we have a series from 5 weeks ago you forgot about suddenly crop up.

So I guess the more nuanced take I have is:

Once we have a robust set up end-to-end _that can handle_ having series that are
deferred to next cycle without risk of things getting mixed up - then that makes
sense, yes.

But while there's still a bit of uncertainty around that, then I'd rather not.

But I think if people DO just resend their stuff in -rc1 then we're OK and it
addresses my concerns.

One thing we could do here is to tag series appropriately like:

[PATCH v7.2] 00/42

To make it clear where it's intended to head to.

P.S. Having the 'quiet period' REALLY REALLY helps. So thanks for that Andrew!

>
> Vlastimil

Thanks, Lorenzo

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[David Hildenbrand (Arm)]

On 4/10/26 14:24, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
>>
>>
>> On 10/04/2026 12:57, Lorenzo Stoakes wrote:
>>>
>>> (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
>>> won't be taking anything new until then. We plan to do this from around rc5 or
>>> rc6 of each cycle in future).
>>
>> Thanks! Just wanted to check, as I am always confused about this. Is it ok
>> to send patches for review for next release at this time? So that they
>> are in a good state when rc1 comes. I wanted to send PMD swap entries
>> for review after I am finished testing, but I want them for review for
>> next release.
> 
> I think different people have different views on that :)
> 
> I mean it's debateable whether having a glut of new material on day one of -rc1
> is preferable to having a bunch come in that might or might not get lost along
> the way :)
> 
> I personally feel it'd be better to send during the cycle window rather than
> before but I suspect others disagree with that!
> 
> So from your point of view, feel free to do what you like, but maybe David +
> others would want to chime in with their opinions?

I personally don't care that much. People just have to be prepared that
there will be little review on new (non-fix) material during the quiet
period.

It will sit in my inbox one way or the other :)

-- 
Cheers,

David

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Usama Arif]

On 10/04/2026 12:55, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
>>
>>
>> On 02/04/2026 19:08, Usama Arif wrote:
>>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
>>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
>>>   to HPAGE_PMD_SIZE limited to 2M (Rui)
>>> - Reviewed-by tags for patch 1 from Kiryl and Jan
>>> - Remove preferred_exec_order() (Jan)
>>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
>>>   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
>>>   do_sync_mmap_readahead().
>>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
>>>   page size for arm64.
>>> - remove bprm->file NULL check (Matthew)
>>> - Change filp to file (Matthew)
>>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
>>>
>>
>> Hello!
>>
>> Just wanted to check if there was any feedback/review on the latest
>> revision?
> 
> It's -rc7, this is definitely something for next cycle :)
> 

Yeah no worries! Just wanted to check what people thought about it!

> On my part, my upstream bandwidth has drastically reduced, and review is
> probably going to have to be a hobbyist thing at least for now.
> 
> Also, not to be mean but:
> 
> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> 21
> 
> So... :)
> 
> Review in mm is very lop-sided, let's try to balance it out a bit!
> 

Ah yeah actually I have been reviewing a lot over the last few months.
I dont ack patches that have already been acked-by/reviewed-by maintainers.
as I am not sure if it adds anything. I never really cared about Reviewed/Acked
by/patch count but I can start adding tags if it helps in stats.

The reviews I have done over the last week alone:
https://lore.kernel.org/all/20260408122307.1360475-1-usama.arif@linux.dev/ 
https://lore.kernel.org/all/20260408123700.1596800-1-usama.arif@linux.dev/ 
https://lore.kernel.org/all/20260409142256.131676-1-usama.arif@linux.dev/ 
https://lore.kernel.org/all/20260410114809.3592720-1-usama.arif@linux.dev/ 
https://lore.kernel.org/all/20260410112433.3248586-1-usama.arif@linux.dev/ 
https://lore.kernel.org/all/20260331103451.1070175-1-usama.arif@linux.dev/T/#t 
https://lore.kernel.org/all/20260401152343.3294686-1-usama.arif@linux.dev/ 

Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory

[Lorenzo Stoakes]

On Fri, Apr 10, 2026 at 01:05:40PM +0100, Usama Arif wrote:
>
>
> On 10/04/2026 12:55, Lorenzo Stoakes wrote:
> > On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
> >>
> >>
> >> On 02/04/2026 19:08, Usama Arif wrote:
> >>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> >>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> >>>   to HPAGE_PMD_SIZE limited to 2M (Rui)
> >>> - Reviewed-by tags for patch 1 from Kiryl and Jan
> >>> - Remove preferred_exec_order() (Jan)
> >>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> >>>   otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> >>>   do_sync_mmap_readahead().
> >>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> >>>   page size for arm64.
> >>> - remove bprm->file NULL check (Matthew)
> >>> - Change filp to file (Matthew)
> >>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> >>>
> >>
> >> Hello!
> >>
> >> Just wanted to check if there was any feedback/review on the latest
> >> revision?
> >
> > It's -rc7, this is definitely something for next cycle :)
> >
>
> Yeah no worries! Just wanted to check what people thought about it!

We'll come back to it! With LSF coming too I think people are fairly distracted
as well.

>
> > On my part, my upstream bandwidth has drastically reduced, and review is
> > probably going to have to be a hobbyist thing at least for now.
> >
> > Also, not to be mean but:
> >
> > $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> > 21
> >
> > So... :)
> >
> > Review in mm is very lop-sided, let's try to balance it out a bit!
> >
>
> Ah yeah actually I have been reviewing a lot over the last few months.

Good :)

> I dont ack patches that have already been acked-by/reviewed-by maintainers.

You should do that, it is meaningful. If you think a patch is OK, it's how you
say so!

Maintainers get things wrong too by the way, assume we are wrong and try to find
issues, this is how a healthy technical community operates (as long as everybody
is civil about it :)

> as I am not sure if it adds anything. I never really cared about Reviewed/Acked
> by/patch count but I can start adding tags if it helps in stats.

It's the only metric I can quickly bring up, so sorry that in this case I got it
wrong, but the overall point remains the same - we want to see a balance of
review and contributions, right now the two are really very lopsided!

>
> The reviews I have done over the last week alone:
> https://lore.kernel.org/all/20260408122307.1360475-1-usama.arif@linux.dev/
> https://lore.kernel.org/all/20260408123700.1596800-1-usama.arif@linux.dev/
> https://lore.kernel.org/all/20260409142256.131676-1-usama.arif@linux.dev/
> https://lore.kernel.org/all/20260410114809.3592720-1-usama.arif@linux.dev/
> https://lore.kernel.org/all/20260410112433.3248586-1-usama.arif@linux.dev/
> https://lore.kernel.org/all/20260331103451.1070175-1-usama.arif@linux.dev/T/#t
> https://lore.kernel.org/all/20260401152343.3294686-1-usama.arif@linux.dev/
>
>
>
>
>

Cheers, Lorenzo