All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Baolin Wang <baolin.wang@linux.alibaba.com>,
	akpm@linux-foundation.org, ljs@kernel.org, hannes@cmpxchg.org
Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org,
	harry@kernel.org, jannh@google.com, lance.yang@linux.dev,
	kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev,
	baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com,
	weixugc@google.com, mhocko@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm: mglru: promote mapped executable folios after first usage
Date: Thu, 16 Jul 2026 13:10:38 +0200	[thread overview]
Message-ID: <a00664d4-01a0-413c-bc33-71c86cce7894@kernel.org> (raw)
In-Reply-To: <7e3a5f6bdf70e0237027025f4593a3874d411f65.1784197559.git.baolin.wang@linux.alibaba.com>

On 7/16/26 12:46, Baolin Wang 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() or lru_gen_set_refs() 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 easily.
> 
> Follow the classical LRU's logic, promoting mapped executable file folios
> after their first usage in folio_update_gen() and lru_gen_set_refs(),
> 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>
> ---
>  include/linux/mm_inline.h |  6 ++++++
>  mm/vmscan.c               | 41 ++++++++++++++++++++++++---------------
>  2 files changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> index b5c4dc0f3fe3..30fdf1056312 100644
> --- a/include/linux/mm_inline.h
> +++ b/include/linux/mm_inline.h
> @@ -30,6 +30,12 @@ static inline int folio_is_file_lru(const struct folio *folio)
>  	return !folio_test_swapbacked(folio);
>  }
>  
> +static inline bool folio_is_exec_file(const struct folio *folio,
> +		const vma_flags_t *vma_flags)
> +{
> +	return vma_flags_test(vma_flags, VMA_EXEC_BIT) && folio_is_file_lru(folio);
> +}

I don't quite like a generic folio_is* helper to consume vma flags. Whether it
is executable depends on the VMA. When called from a non-exec VMA it would just
give a wrong answer.

Not sure if something like "is_executable_file_folio()"/"is_exec_file_folio"
would be better, to distinguish from the actualy folio_is* helpers that are
independent of context.

Also, can this helper just go to vmscan.c?

-- 
Cheers,

David

  reply	other threads:[~2026-07-16 11:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 10:46 [PATCH v2 0/2] promote mapped executable folios after first usage for MGLRU Baolin Wang
2026-07-16 10:46 ` [PATCH v2 1/2] mm: vmscan: convert folio_referenced() to use vma_flags_t Baolin Wang
2026-07-16 11:00   ` David Hildenbrand (Arm)
2026-07-16 10:46 ` [PATCH v2 2/2] mm: mglru: promote mapped executable folios after first usage Baolin Wang
2026-07-16 11:10   ` David Hildenbrand (Arm) [this message]
2026-07-16 12:11     ` Baolin Wang

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=a00664d4-01a0-413c-bc33-71c86cce7894@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=hannes@cmpxchg.org \
    --cc=harry@kernel.org \
    --cc=jannh@google.com \
    --cc=kasong@tencent.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=qi.zheng@linux.dev \
    --cc=riel@surriel.com \
    --cc=shakeel.butt@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.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 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.