On Tue, Dec 19, 2023 at 04:00:33PM -0800, Andrew Morton wrote: > On Wed, 20 Dec 2023 07:17:53 +0800 Kevin Hao <haokexin@xxxxxxxxx> wrote: > > > A freezable kernel thread can enter frozen state during freezing by > > either calling try_to_freeze() or using wait_event_freezable() and its > > variants. However, there is no need to use both methods simultaneously. > > The freezable wait variants have been used in khugepaged_wait_work() > > and khugepaged_alloc_sleep(), so remove this redundant > > try_to_freeze(). > > > > ... > > > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -2500,7 +2500,7 @@ static void khugepaged_do_scan(struct collapse_control *cc) > > while (true) { > > cond_resched(); > > > > - if (unlikely(kthread_should_stop() || try_to_freeze())) > > + if (unlikely(kthread_should_stop())) > > break; > > > > spin_lock(&khugepaged_mm_lock); > > What are the effects upon worst-case freezing latency? I used the following stress-ng command to generate some memory load on my Intel Alder Lake board (24 CPUs, 32G memory). stress-ng --vm 48 --vm-bytes 90% The worst freezing latency is: Freezing user space processes Freezing user space processes completed (elapsed 0.040 seconds) OOM killer disabled. Freezing remaining freezable tasks Freezing remaining freezable tasks completed (elapsed 0.001 seconds) Without the faked memory load, the freezing latency is: Freezing user space processes Freezing user space processes completed (elapsed 0.000 seconds) OOM killer disabled. Freezing remaining freezable tasks Freezing remaining freezable tasks completed (elapsed 0.001 seconds) I didn't see any observable difference whether this patch is applied or not. Thanks, Kevin
Attachment:
signature.asc
Description: PGP signature