Re: [PATCH 1/2] fs/epoll: mark epoll_wait tasks TASK_FREEZABLE
From: Sadrul Chowdhury
Date: Thu Sep 24 2026 - 08:31:40 EST
On Wed, Sep 23, 2026 at 7:24 AM Jan Kara <jack@xxxxxxx> wrote:
>
> On Tue 22-09-26 21:15:58, Sadrul Chowdhury wrote:
> > During system suspend (freeze_processes) and resume (thaw_processes),
> > threads blocked in epoll_wait() sleep in TASK_INTERRUPTIBLE. When
> > try_to_freeze_tasks() executes, it must wake up every sleeping thread
> > with a synthetic signal so the thread can schedule, run try_to_freeze(),
> > enter TASK_FROZEN, and sleep again. Upon resume, the freezer wakes them
> > all up simultaneously, only for each thread to re-enter ep_poll(),
> > observe no ready I/O events, and call schedule() to go back to sleep.
> >
> > On systems with numerous event-driven daemons (where hundreds of
> > threads idle in event loops), this causes a large wakeup stampede and
> > thousands of redundant context switches per suspend/resume cycle.
> >
> > An earlier attempt to make epoll_wait() freezable in commit 1c441e921201
> > ("epoll: use freezable blocking call") was reverted in commit
> > c511851de162 ("Revert "epoll: use freezable blocking call"") due to
> > reports of userspace corruption (Bugzilla #61781). Under the legacy
> > freezer design, freezable tasks could wake up prematurely while
> > hardware and peripheral drivers were still suspended.
> >
> > With the 2022 core freezer rewrite (commit f5d39b020809 ("freezer,sched:
> > Rewrite core freezer logic")), the legacy fake-signal mechanism was
> > replaced with the TASK_FROZEN state. Tasks sleeping in TASK_FREEZABLE
> > are safely frozen in-place without waking them up, and the scheduler
> > guarantees they cannot be woken until thaw_processes() explicitly clears
> > the frozen state.
> >
> > Mark sleeping tasks in ep_poll() as TASK_FREEZABLE. Benchmarks on an
> > ARM64 test device demonstrate that combining this with freezable
> > select/poll reduces thaw latency by 63% (from 20.64 ms down to 7.55 ms
> > mean at fixed CPU frequency) and reduces context switches during
> > freeze/thaw by 87%.
> >
> > Signed-off-by: Sadrul Chowdhury <sadrul@xxxxxxxxxx>
>
> With similar caveat as on patch 2/2 feel free to add:
>
> Reviewed-by: Jan Kara <jack@xxxxxxx>
>
Thank you for the review!
Regards,
Sadrul
> Honza
>
> > ---
> > fs/eventpoll.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> > index 6cbef8b4c2e0..35992f6457bf 100644
> > --- a/fs/eventpoll.c
> > +++ b/fs/eventpoll.c
> > @@ -39,6 +39,7 @@
> > #include <linux/rculist.h>
> > #include <linux/capability.h>
> > #include <net/busy_poll.h>
> > +#include <linux/freezer.h>
> >
> > #include <trace/hooks/fs.h>
> >
> > @@ -1987,7 +1988,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
> > * the same lock on wakeup ep_poll_callback() side, so it
> > * is safe to avoid an explicit barrier.
> > */
> > - __set_current_state(TASK_INTERRUPTIBLE);
> > + __set_current_state(TASK_INTERRUPTIBLE | TASK_FREEZABLE);
> >
> > /*
> > * Do the final check under the lock. ep_start/done_scan()
> > --
> > 2.55.0.1082.g2b9226bbc0-goog
> >
> --
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR