From: Michal Hocko <mhocko@suse.com>
To: Lance Yang <ioworker0@gmail.com>
Cc: akpm@linux-foundation.org, zokeefe@google.com, david@redhat.com,
songmuchun@bytedance.com, shy828301@gmail.com, peterx@redhat.com,
minchan@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE_THP check
Date: Tue, 30 Jan 2024 10:35:40 +0100 [thread overview]
Message-ID: <ZbjC7KyI21ik1xpK@tiehlicka> (raw)
In-Reply-To: <CAK1f24=2YE+BCYiizkqc8rmN8NaFv_Q6ZtE+4DiFK0PpcefOrQ@mail.gmail.com>
On Tue 30-01-24 11:08:10, Lance Yang wrote:
> On Tue, Jan 30, 2024 at 10:12 AM Lance Yang <ioworker0@gmail.com> wrote:
> >
> > Hey Michal,
> >
> > Thanks for taking time to review!
> >
> > 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.
OK, this is an important detail. Something that should be a part
of the chnagelog. It is also important to note that this is not
a correctness issue but rather an optimization to save expensive
checks on each VMA when userspace cannot prctl itself before spawning
into the new process.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-01-30 9:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 5:45 [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE_THP check Lance Yang
2024-01-29 16:28 ` Michal Hocko
2024-01-30 2:12 ` Lance Yang
2024-01-30 3:08 ` Lance Yang
2024-01-30 9:35 ` Michal Hocko [this message]
2024-01-30 9:46 ` Lance Yang
2024-01-31 0:37 ` Lance Yang
2024-01-29 18:53 ` Yang Shi
2024-01-29 19:03 ` Zach O'Keefe
2024-01-30 2:37 ` Lance Yang
2024-01-30 2:21 ` Lance Yang
2024-01-31 9:30 ` Lance Yang
2024-01-31 20:06 ` Yang Shi
2024-02-01 1:13 ` Lance Yang
2024-02-01 18:56 ` Yang Shi
2024-02-03 3:20 ` Lance Yang
2024-02-21 22:11 ` Andrew Morton
2024-02-22 7:43 ` Lance Yang
2024-02-22 7:51 ` Lance Yang
2024-02-22 8:51 ` David Hildenbrand
2024-02-22 9:12 ` Lance Yang
2024-02-22 20:23 ` Yang Shi
2024-02-22 21:11 ` Andrew Morton
2024-02-23 7:59 ` Lance Yang
2024-02-24 1:47 ` Yang Shi
2024-02-24 1:46 ` Yang Shi
2024-02-24 3:54 ` Lance Yang
2024-02-25 4:56 ` Lance Yang
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=ZbjC7KyI21ik1xpK@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=peterx@redhat.com \
--cc=shy828301@gmail.com \
--cc=songmuchun@bytedance.com \
--cc=zokeefe@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.