On Tue, Jan 30, 2024 at 10:12 AM Lance Yang <ioworker0@xxxxxxxxx> 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. > > BR, > Lance > > On Tue, Jan 30, 2024 at 12:28 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Mon 29-01-24 13:45:51, Lance Yang wrote: > > > 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. > > > > Is this a real problem? I thought that the prctl is called > > on the parent before fork/exec. Or are you aware of any > > applications which do call prctl late enough that the race > > would be actually observable? > > -- > > Michal Hocko > > SUSE Labs
