[PATCH] mm: mglru: promote mapped executable folios after first usage

[PATCH] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

Classical LRU protects mapped executable file folios through commit
8cab4754d24a0 ("vmscan: make mapped executable pages the first class
citizen") and commit c909e99364c8 ("vmscan: activate executable pages
after first usage"), giving executable code a better chance to stay in
memory, avoiding IO thrashing and improving workload performance.

However, MGLRU's protection of mapped executable file folios is less
reliable. Although shrink_folio_list() checks references, the access flag
of mapped executable file folios may have already been checked and
cleared by lru_gen_look_around() or walk_mm(). Additionally,
folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
file folios, which causes shrink_folio_list() to ignore the first usage
of these mapped executable file folios and reclaim them.

Follow the classical LRU's logic, promoting mapped executable file folios
after their first usage in folio_update_gen(), giving executable code a
better chance to stay in memory.

On my 32-core Arm machine, with the memcg limit set to 2G, running
'make -j32' to build kernel showed some improvement in sys time.

base			patched
9248.543s		7861.579s

Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
 mm/vmscan.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 986dde8e7429..429857852bdb 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3188,7 +3188,7 @@ static bool positive_ctrl_err(struct ctrl_pos *sp, struct ctrl_pos *pv)
  ******************************************************************************/
 
 /* promote pages accessed through page tables */
-static int folio_update_gen(struct folio *folio, int gen)
+static int folio_update_gen(struct vm_area_struct *vma, struct folio *folio, int gen)
 {
 	unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f);
 
@@ -3196,10 +3196,15 @@ static int folio_update_gen(struct folio *folio, int gen)
 
 	/* see the comment on LRU_REFS_FLAGS */
 	if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) {
+		/* Activate file-backed executable folios after first usage. */
+		if (vma_test(vma, VMA_EXEC_BIT) && folio_is_file_lru(folio))
+			goto promote;
+
 		set_mask_bits(&folio->flags.f, LRU_REFS_MASK, BIT(PG_referenced));
 		return -1;
 	}
 
+promote:
 	do {
 		/* lru_gen_del_folio() has isolated this page? */
 		if (!(old_flags & LRU_GEN_MASK))
@@ -3428,8 +3433,8 @@ static bool suitable_to_scan(int total, int young)
 	return young * n >= total;
 }
 
-static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
-			      int new_gen, bool dirty)
+static void walk_update_folio(struct lru_gen_mm_walk *walk, struct vm_area_struct *vma,
+		struct folio *folio, int new_gen, bool dirty)
 {
 	int old_gen;
 
@@ -3442,7 +3447,7 @@ static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
 		folio_mark_dirty(folio);
 
 	if (walk) {
-		old_gen = folio_update_gen(folio, new_gen);
+		old_gen = folio_update_gen(vma, folio, new_gen);
 		if (old_gen >= 0 && old_gen != new_gen)
 			update_batch_size(walk, folio, old_gen, new_gen);
 	} else if (lru_gen_set_refs(folio)) {
@@ -3518,7 +3523,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 			continue;
 
 		if (last != folio) {
-			walk_update_folio(walk, last, gen, dirty);
+			walk_update_folio(walk, args->vma, last, gen, dirty);
 
 			last = folio;
 			dirty = false;
@@ -3531,7 +3536,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 		walk->mm_stats[MM_LEAF_YOUNG] += nr;
 	}
 
-	walk_update_folio(walk, last, gen, dirty);
+	walk_update_folio(walk, args->vma, last, gen, dirty);
 	last = NULL;
 
 	if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
@@ -3609,7 +3614,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 			goto next;
 
 		if (last != folio) {
-			walk_update_folio(walk, last, gen, dirty);
+			walk_update_folio(walk, vma, last, gen, dirty);
 
 			last = folio;
 			dirty = false;
@@ -3623,7 +3628,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 		i = i > MIN_LRU_BATCH ? 0 : find_next_bit(bitmap, MIN_LRU_BATCH, i) + 1;
 	} while (i <= MIN_LRU_BATCH);
 
-	walk_update_folio(walk, last, gen, dirty);
+	walk_update_folio(walk, vma, last, gen, dirty);
 
 	lazy_mmu_mode_disable();
 	spin_unlock(ptl);
@@ -4258,7 +4263,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
 			continue;
 
 		if (last != folio) {
-			walk_update_folio(walk, last, gen, dirty);
+			walk_update_folio(walk, vma, last, gen, dirty);
 
 			last = folio;
 			dirty = false;
@@ -4270,7 +4275,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
 		young += nr;
 	}
 
-	walk_update_folio(walk, last, gen, dirty);
+	walk_update_folio(walk, vma, last, gen, dirty);
 
 	lazy_mmu_mode_disable();
 
-- 
2.47.3

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Barry Song]

On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
> Classical LRU protects mapped executable file folios through commit
> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
> citizen") and commit c909e99364c8 ("vmscan: activate executable pages
> after first usage"), giving executable code a better chance to stay in
> memory, avoiding IO thrashing and improving workload performance.
>
> However, MGLRU's protection of mapped executable file folios is less
> reliable. Although shrink_folio_list() checks references, the access flag
> of mapped executable file folios may have already been checked and
> cleared by lru_gen_look_around() or walk_mm(). Additionally,
> folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
> file folios, which causes shrink_folio_list() to ignore the first usage
> of these mapped executable file folios and reclaim them.
>
> Follow the classical LRU's logic, promoting mapped executable file folios
> after their first usage in folio_update_gen(), giving executable code a
> better chance to stay in memory.
>
> On my 32-core Arm machine, with the memcg limit set to 2G, running
> 'make -j32' to build kernel showed some improvement in sys time.

Hi Baolin,

Because ARM doesn't set the surrounding PTEs to young, while x86
may behave differently and mark the surrounding PTEs as young as
well. Could we also collect the data on x86?

void set_pte_range(struct vm_fault *vmf, struct folio *folio,
                struct page *page, unsigned int nr, unsigned long addr)
{
        ...

        if (prefault && arch_wants_old_prefaulted_pte())
                entry = pte_mkold(entry);
        else
                entry = pte_sw_mkyoung(entry);

>
> base                    patched
> 9248.543s               7861.579s
>
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>

Thanks
Barry

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

On 7/15/26 2:52 PM, Barry Song wrote:
> On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>> Classical LRU protects mapped executable file folios through commit
>> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
>> citizen") and commit c909e99364c8 ("vmscan: activate executable pages
>> after first usage"), giving executable code a better chance to stay in
>> memory, avoiding IO thrashing and improving workload performance.
>>
>> However, MGLRU's protection of mapped executable file folios is less
>> reliable. Although shrink_folio_list() checks references, the access flag
>> of mapped executable file folios may have already been checked and
>> cleared by lru_gen_look_around() or walk_mm(). Additionally,
>> folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
>> file folios, which causes shrink_folio_list() to ignore the first usage
>> of these mapped executable file folios and reclaim them.
>>
>> Follow the classical LRU's logic, promoting mapped executable file folios
>> after their first usage in folio_update_gen(), giving executable code a
>> better chance to stay in memory.
>>
>> On my 32-core Arm machine, with the memcg limit set to 2G, running
>> 'make -j32' to build kernel showed some improvement in sys time.
> 
> Hi Baolin,
> 
> Because ARM doesn't set the surrounding PTEs to young, while x86
> may behave differently and mark the surrounding PTEs as young as
> well. Could we also collect the data on x86?
> 
> void set_pte_range(struct vm_fault *vmf, struct folio *folio,
>                  struct page *page, unsigned int nr, unsigned long addr)
> {
>          ...
> 
>          if (prefault && arch_wants_old_prefaulted_pte())
>                  entry = pte_mkold(entry);
>          else
>                  entry = pte_sw_mkyoung(entry);

Sure. But I don't think it's very relevant to this point. MGLRU doesn't 
protect normally accessed mmaped exec file folios well enough. Anyway, 
I'll test it on x86.

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Barry Song]

On Wed, Jul 15, 2026 at 2:58 PM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
>
>
> On 7/15/26 2:52 PM, Barry Song wrote:
> > On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
> > <baolin.wang@linux.alibaba.com> wrote:
> >>
> >> Classical LRU protects mapped executable file folios through commit
> >> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
> >> citizen") and commit c909e99364c8 ("vmscan: activate executable pages
> >> after first usage"), giving executable code a better chance to stay in
> >> memory, avoiding IO thrashing and improving workload performance.
> >>
> >> However, MGLRU's protection of mapped executable file folios is less
> >> reliable. Although shrink_folio_list() checks references, the access flag
> >> of mapped executable file folios may have already been checked and
> >> cleared by lru_gen_look_around() or walk_mm(). Additionally,
> >> folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
> >> file folios, which causes shrink_folio_list() to ignore the first usage
> >> of these mapped executable file folios and reclaim them.
> >>
> >> Follow the classical LRU's logic, promoting mapped executable file folios
> >> after their first usage in folio_update_gen(), giving executable code a
> >> better chance to stay in memory.
> >>
> >> On my 32-core Arm machine, with the memcg limit set to 2G, running
> >> 'make -j32' to build kernel showed some improvement in sys time.
> >
> > Hi Baolin,
> >
> > Because ARM doesn't set the surrounding PTEs to young, while x86
> > may behave differently and mark the surrounding PTEs as young as
> > well. Could we also collect the data on x86?
> >
> > void set_pte_range(struct vm_fault *vmf, struct folio *folio,
> >                  struct page *page, unsigned int nr, unsigned long addr)
> > {
> >          ...
> >
> >          if (prefault && arch_wants_old_prefaulted_pte())
> >                  entry = pte_mkold(entry);
> >          else
> >                  entry = pte_sw_mkyoung(entry);
>
> Sure. But I don't think it's very relevant to this point. MGLRU doesn't
> protect normally accessed mmaped exec file folios well enough. Anyway,
> I'll test it on x86.

My point is that even mmaped executable folios that have never been
accessed might still get promoted because they already have the accessed
bit set. :-)

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Barry Song]

On Wed, Jul 15, 2026 at 3:54 PM Barry Song <baohua@kernel.org> wrote:
[...]
> > >
> > > Hi Baolin,
> > >
> > > Because ARM doesn't set the surrounding PTEs to young, while x86
> > > may behave differently and mark the surrounding PTEs as young as
> > > well. Could we also collect the data on x86?
> > >
> > > void set_pte_range(struct vm_fault *vmf, struct folio *folio,
> > >                  struct page *page, unsigned int nr, unsigned long addr)
> > > {
> > >          ...
> > >
> > >          if (prefault && arch_wants_old_prefaulted_pte())
> > >                  entry = pte_mkold(entry);
> > >          else
> > >                  entry = pte_sw_mkyoung(entry);
> >
> > Sure. But I don't think it's very relevant to this point. MGLRU doesn't
> > protect normally accessed mmaped exec file folios well enough. Anyway,
> > I'll test it on x86.
>
> My point is that even mmaped executable folios that have never been
> accessed might still get promoted because they already have the accessed
> bit set. :-)

Second thought: we don't do much readahead for VM_EXEC since it is
considered random access. So maybe I am being over-cautious here.
The data will tell us :-)

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

On 7/15/26 3:57 PM, Barry Song wrote:
> On Wed, Jul 15, 2026 at 3:54 PM Barry Song <baohua@kernel.org> wrote:
> [...]
>>>>
>>>> Hi Baolin,
>>>>
>>>> Because ARM doesn't set the surrounding PTEs to young, while x86
>>>> may behave differently and mark the surrounding PTEs as young as
>>>> well. Could we also collect the data on x86?
>>>>
>>>> void set_pte_range(struct vm_fault *vmf, struct folio *folio,
>>>>                   struct page *page, unsigned int nr, unsigned long addr)
>>>> {
>>>>           ...
>>>>
>>>>           if (prefault && arch_wants_old_prefaulted_pte())
>>>>                   entry = pte_mkold(entry);
>>>>           else
>>>>                   entry = pte_sw_mkyoung(entry);
>>>
>>> Sure. But I don't think it's very relevant to this point. MGLRU doesn't
>>> protect normally accessed mmaped exec file folios well enough. Anyway,
>>> I'll test it on x86.
>>
>> My point is that even mmaped executable folios that have never been
>> accessed might still get promoted because they already have the accessed
>> bit set. :-)
> 
> Second thought: we don't do much readahead for VM_EXEC since it is
> considered random access. So maybe I am being over-cautious here.
> The data will tell us :-)

Yes. Besides, even if an exec folio gets promoted incorrectly at first, 
it can still be reclaimed as it ages without further accesses. This is 
the same logic as the classical LRU.

I did a quick test with the same test case on my x86 machine, and I 
still see an improvement in sys time.

base			patched
1152.249s		993.235s

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Kairui Song]

On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:

Hi Baolin,
>
> Classical LRU protects mapped executable file folios through commit
> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
> citizen") and commit c909e99364c8 ("vmscan: activate executable pages
> after first usage"), giving executable code a better chance to stay in
> memory, avoiding IO thrashing and improving workload performance.

That's really a long history for those two commits :)
>
> However, MGLRU's protection of mapped executable file folios is less
> reliable. Although shrink_folio_list() checks references, the access flag
> of mapped executable file folios may have already been checked and
> cleared by lru_gen_look_around() or walk_mm(). Additionally,
> folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
> file folios, which causes shrink_folio_list() to ignore the first usage
> of these mapped executable file folios and reclaim them.
>
> Follow the classical LRU's logic, promoting mapped executable file folios
> after their first usage in folio_update_gen(), giving executable code a
> better chance to stay in memory.

Yeah I think that's mostly an ideology issue, recently upstream tends
to treat all folios fairly if there is no particular reason.
Personally I also agree that some folios are more special compared to
other though.

> On my 32-core Arm machine, with the memcg limit set to 2G, running
> 'make -j32' to build kernel showed some improvement in sys time.
>
> base                    patched
> 9248.543s               7861.579s
>
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
>  mm/vmscan.c | 25 +++++++++++++++----------
>  1 file changed, 15 insertions(+), 10 deletions(-)

MGLRU used to favor and put all map faulted memory at head, so could
this be related to a recent change in any way?
https://lore.kernel.org/linux-mm/20260526130938.66253-1-baohua@kernel.org/

>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 986dde8e7429..429857852bdb 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3188,7 +3188,7 @@ static bool positive_ctrl_err(struct ctrl_pos *sp, struct ctrl_pos *pv)
>   ******************************************************************************/
>
>  /* promote pages accessed through page tables */
> -static int folio_update_gen(struct folio *folio, int gen)
> +static int folio_update_gen(struct vm_area_struct *vma, struct folio *folio, int gen)
>  {
>         unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f);
>
> @@ -3196,10 +3196,15 @@ static int folio_update_gen(struct folio *folio, int gen)
>
>         /* see the comment on LRU_REFS_FLAGS */
>         if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) {
> +               /* Activate file-backed executable folios after first usage. */
> +               if (vma_test(vma, VMA_EXEC_BIT) && folio_is_file_lru(folio))
> +                       goto promote;
> +

Do you think it's a good idea to extract this into a helper e.g.
folio_is_executable_file?

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Andrew Morton]

On Wed, 15 Jul 2026 17:00:19 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:

> I did a quick test with the same test case on my x86 machine, and I 
> still see an improvement in sys time.
> 
> base			patched
> 1152.249s		993.235s

Nice.  Sashiko asked a thing:
	https://sashiko.dev/#/patchset/4b921ed528c483e13c9e22d1ae44ba58b4a15b0b.1784096432.git.baolin.wang@linux.alibaba.com

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

On 7/16/26 12:50 AM, Kairui Song wrote:
> On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
> 
> Hi Baolin,
>>
>> Classical LRU protects mapped executable file folios through commit
>> 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
>> citizen") and commit c909e99364c8 ("vmscan: activate executable pages
>> after first usage"), giving executable code a better chance to stay in
>> memory, avoiding IO thrashing and improving workload performance.
> 
> That's really a long history for those two commits :)
>>
>> However, MGLRU's protection of mapped executable file folios is less
>> reliable. Although shrink_folio_list() checks references, the access flag
>> of mapped executable file folios may have already been checked and
>> cleared by lru_gen_look_around() or walk_mm(). Additionally,
>> folio_update_gen() only sets the 'PG_referenced' flag for mapped executable
>> file folios, which causes shrink_folio_list() to ignore the first usage
>> of these mapped executable file folios and reclaim them.
>>
>> Follow the classical LRU's logic, promoting mapped executable file folios
>> after their first usage in folio_update_gen(), giving executable code a
>> better chance to stay in memory.
> 
> Yeah I think that's mostly an ideology issue, recently upstream tends
> to treat all folios fairly if there is no particular reason.
> Personally I also agree that some folios are more special compared to
> other though.

OK.

>> On my 32-core Arm machine, with the memcg limit set to 2G, running
>> 'make -j32' to build kernel showed some improvement in sys time.
>>
>> base                    patched
>> 9248.543s               7861.579s
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> ---
>>   mm/vmscan.c | 25 +++++++++++++++----------
>>   1 file changed, 15 insertions(+), 10 deletions(-)
> 
> MGLRU used to favor and put all map faulted memory at head, so could
> this be related to a recent change in any way?
> https://lore.kernel.org/linux-mm/20260526130938.66253-1-baohua@kernel.org/

I haven't tested Barry's patch yet. Personally, I don't think this is 
closely related to Barry's patch. Though we put the faulted folios into 
the secound youngest gen before, after aging, the mapped exec folios are 
still not protected like in Classical LRU, and can be easily reclaimed.

>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 986dde8e7429..429857852bdb 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -3188,7 +3188,7 @@ static bool positive_ctrl_err(struct ctrl_pos *sp, struct ctrl_pos *pv)
>>    ******************************************************************************/
>>
>>   /* promote pages accessed through page tables */
>> -static int folio_update_gen(struct folio *folio, int gen)
>> +static int folio_update_gen(struct vm_area_struct *vma, struct folio *folio, int gen)
>>   {
>>          unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f);
>>
>> @@ -3196,10 +3196,15 @@ static int folio_update_gen(struct folio *folio, int gen)
>>
>>          /* see the comment on LRU_REFS_FLAGS */
>>          if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) {
>> +               /* Activate file-backed executable folios after first usage. */
>> +               if (vma_test(vma, VMA_EXEC_BIT) && folio_is_file_lru(folio))
>> +                       goto promote;
>> +
> 
> Do you think it's a good idea to extract this into a helper e.g.
> folio_is_executable_file?

Good point. Will do. Thanks.

Re: [PATCH] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

On 7/16/26 3:44 AM, Andrew Morton wrote:
> On Wed, 15 Jul 2026 17:00:19 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
> 
>> I did a quick test with the same test case on my x86 machine, and I
>> still see an improvement in sys time.
>>
>> base			patched
>> 1152.249s		993.235s
> 
> Nice.  Sashiko asked a thing:
> 	https://sashiko.dev/#/patchset/4b921ed528c483e13c9e22d1ae44ba58b4a15b0b.1784096432.git.baolin.wang@linux.alibaba.com

Thanks.

Forward Sashiko's comments:
"
This is a pre-existing issue, but does this miss promoting mapped
executable file folios during direct reclaim?

......

This means current->reclaim_state->mm_walk is NULL. When 
shrink_folio_list() calls folio_referenced(), it invokes 
lru_gen_look_around() which calls walk_update_folio() with a NULL walk. 
Since walk is NULL, we fall back to lru_gen_set_refs() here, which 
bypasses the newly patched folio_update_gen():

mm/vmscan.c:lru_gen_set_refs() {
	if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) {
		set_mask_bits(&folio->flags.f, LRU_REFS_MASK, BIT(PG_referenced));
		return false;
	}
	...
}

Because lru_gen_set_refs() lacks the new VMA_EXEC_BIT promotion logic, 
it merely sets PG_referenced without updating the folio's generation. 
When those adjacent folios are subsequently isolated by 
shrink_folio_list(), their PTE young bits have already been cleared, 
causing folio_check_references() to return FOLIOREF_RECLAIM and evict 
them. Will we need a similar fix for lru_gen_set_refs() to handle direct 
reclaim paths?
"

During aging, MGLRU always sets up a valid mm_walk to walk the page 
table access flags in try_to_inc_max_seq().

When aging is not needed, it is indeed possible to fall into 
lru_gen_set_refs() and miss promoting mapped exec folios after first 
usage. Although I think the impact is limited, because after the current 
patch, accessed mapped exec folios rarely get a chance to enter the 
eviction path. Anyway, I'll add promotion logic for lru_gen_set_refs().