linux-kernel - Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240221141158.8217ff2caf4f86c11a430058@linux-foundation.org>
Date: Wed, 21 Feb 2024 14:11:58 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lance Yang <ioworker0@...il.com>
Cc: mhocko@...e.com, zokeefe@...gle.com, david@...hat.com,
 songmuchun@...edance.com, shy828301@...il.com, peterx@...hat.com,
 minchan@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with
 MMF_DISABLE_THP check

On Wed, 31 Jan 2024 17:30:11 +0800 Lance Yang <ioworker0@...il.com> wrote:

> Updating the change log.
> 
> khugepaged scans the entire address space in the
> background for each given mm, looking for
> opportunities to merge sequences of basic pages
> into huge pages. However, when an mm is inserted
> to the mm_slots list, and the MMF_DISABLE_THP
> flag is set later, this scanning process becomes
> unnecessary for that mm and can be skipped to
> avoid redundant operations, especially in scenarios
> with a large address space.
> 
> This commit introduces a check before each scanning
> process to test the MMF_DISABLE_THP flag for the
> given mm; if the flag is set, the scanning process is
> bypassed, thereby improving the efficiency of khugepaged.
> 
> This optimization is not a correctness issue but rather an
> enhancement to save expensive checks on each VMA
> when userspace cannot prctl itself before spawning
> into the new process.
> 
> On some servers within our company, we deploy a
> daemon responsible for monitoring and updating local
> applications. Some applications prefer not to use THP,
> so the daemon calls prctl to disable THP before fork/exec.
> Conversely, for other applications, the daemon calls prctl
> to enable THP before fork/exec.
> 
> Ideally, the daemon should invoke prctl after the fork,
> but its current implementation follows the described
> approach. In the Go standard library, there is no direct
> encapsulation of the fork system call; instead, fork and
> execve are combined into one through syscall.ForkExec.

I pasted the above into the v1 patch's changelog.

However I'm not seeing a good level of reviewer enthusiasm.  Pertially
because of the lack of quantitative testing results.  Is is possible to
generate such results, to give people an overall feel of the
desirability of this change?