[PATCH v1 0/5] PM: Reduce spurious wakeups

[PATCH v1 0/5] PM: Reduce spurious wakeups

[Dai Junbing]

During system suspend/resume, processes in TASK_INTERRUPTIBLE sleep may
be spuriously woken, causing measurable overhead. When many processes 
are in TASK_INTERRUPTIBLE state during frequent suspend/resume cycles, 
this overhead becomes non-trivial - observed particularly on Android 
mobile devices.
 
Power instrumentation on my Android test device revealed numerous 
processes blocked in:
- epoll_wait(2)
- select(2)
- poll(2)
These processes experienced spurious wakeups during suspend/resume,
contributing to power consumption.
 
After optimizing these wakeups (driver modifications handled outside
this patchset), measurements show 58% reduction in energy consumption
during suspend/resume cycles.

Therefore, minimizing spurious wakeups during suspend/resume transitions
is essential for mobile power efficiency. Please review this series..


Dai Junbing (5):
  epoll: Make epoll_wait sleep freezable
  select/poll: Make sleep freezable
  pipe: Add TASK_FREEZABLE to read and open sleeps
  fuse: Add TASK_FREEZABLE to device read operations
  jbd2: Add TASK_FREEZABLE to kjournald2 thread

 fs/eventpoll.c    | 2 +-
 fs/fuse/dev.c     | 2 +-
 fs/jbd2/journal.c | 2 +-
 fs/pipe.c         | 4 ++--
 fs/select.c       | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.25.1

[PATCH v1 1/5] epoll: Make epoll_wait sleep freezable

[Dai Junbing]

When a user process enters TASK_INTERRUPTIBLE using the epoll_wait(2)
system call and its variants, add the TASK_FREEZABLE flag to prevent the
process from being prematurely awakened during suspend/resume, thus
avoiding unnecessary wakeups and overhead.

ep_poll is only used within the paths of epoll_wait-related system
calls.
In this path, after the process enters sleep, no kernel locks are held.
Therefore, adding TASK_FREEZABLE is safe.

Signed-off-by: Dai Junbing <daijunbing@vivo.com>
---
 fs/eventpoll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 0fbf5dfedb24..d52bd9838ef5 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2094,7 +2094,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.25.1

[PATCH v1 2/5] select/poll: Make sleep freezable

[Dai Junbing]

When processes sleep in TASK_INTERRUPTIBLE state during select(2)
or poll(2) system calls, add the TASK_FREEZABLE flag. This prevents
them from being prematurely awakened during system suspend/resume
operations, avoiding unnecessary wakeup overhead.

The functions do_select() and do_poll() are exclusively used within
their respective system call paths. During sleep in these paths, no
kernel locks are held. Therefore, adding TASK_FREEZABLE is safe.

Signed-off-by: Dai Junbing <daijunbing@vivo.com>
---
 fs/select.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/select.c b/fs/select.c
index 9fb650d03d52..8a1e9fe12650 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -600,7 +600,7 @@ static noinline_for_stack int do_select(int n, fd_set_bits *fds, struct timespec
 			to = &expire;
 		}
 
-		if (!poll_schedule_timeout(&table, TASK_INTERRUPTIBLE,
+		if (!poll_schedule_timeout(&table, TASK_INTERRUPTIBLE | TASK_FREEZABLE,
 					   to, slack))
 			timed_out = 1;
 	}
@@ -955,7 +955,7 @@ static int do_poll(struct poll_list *list, struct poll_wqueues *wait,
 			to = &expire;
 		}
 
-		if (!poll_schedule_timeout(wait, TASK_INTERRUPTIBLE, to, slack))
+		if (!poll_schedule_timeout(wait, TASK_INTERRUPTIBLE | TASK_FREEZABLE, to, slack))
 			timed_out = 1;
 	}
 	return count;
-- 
2.25.1

Re: [PATCH v1 2/5] select/poll: Make sleep freezable

[Jan Kara]

On Wed 30-07-25 09:47:03, Dai Junbing wrote:
> When processes sleep in TASK_INTERRUPTIBLE state during select(2)
> or poll(2) system calls, add the TASK_FREEZABLE flag. This prevents
> them from being prematurely awakened during system suspend/resume
> operations, avoiding unnecessary wakeup overhead.
> 
> The functions do_select() and do_poll() are exclusively used within
> their respective system call paths. During sleep in these paths, no
> kernel locks are held. Therefore, adding TASK_FREEZABLE is safe.
> 
> Signed-off-by: Dai Junbing <daijunbing@vivo.com>

This looks sensible to me. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/select.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/select.c b/fs/select.c
> index 9fb650d03d52..8a1e9fe12650 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -600,7 +600,7 @@ static noinline_for_stack int do_select(int n, fd_set_bits *fds, struct timespec
>  			to = &expire;
>  		}
>  
> -		if (!poll_schedule_timeout(&table, TASK_INTERRUPTIBLE,
> +		if (!poll_schedule_timeout(&table, TASK_INTERRUPTIBLE | TASK_FREEZABLE,
>  					   to, slack))
>  			timed_out = 1;
>  	}
> @@ -955,7 +955,7 @@ static int do_poll(struct poll_list *list, struct poll_wqueues *wait,
>  			to = &expire;
>  		}
>  
> -		if (!poll_schedule_timeout(wait, TASK_INTERRUPTIBLE, to, slack))
> +		if (!poll_schedule_timeout(wait, TASK_INTERRUPTIBLE | TASK_FREEZABLE, to, slack))
>  			timed_out = 1;
>  	}
>  	return count;
> -- 
> 2.25.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH v1 3/5] pipe: Add TASK_FREEZABLE to read and open sleeps

[Dai Junbing]

When a process sleeps during read on pipes or open on FIFOs,
add the TASK_FREEZABLE flag. This prevents premature wakeups during
system suspend/resume operations, avoiding unnecessary wakeup overhead.

In both the pipe read and FIFO open paths, no kernel locks are held
during sleep. Therefore, adding TASK_FREEZABLE is safe.

Signed-off-by: Dai Junbing <daijunbing@vivo.com>
---
 fs/pipe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index 45077c37bad1..b49e382c59ba 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -385,7 +385,7 @@ anon_pipe_read(struct kiocb *iocb, struct iov_iter *to)
 		 * since we've done any required wakeups and there's no need
 		 * to mark anything accessed. And we've dropped the lock.
 		 */
-		if (wait_event_interruptible_exclusive(pipe->rd_wait, pipe_readable(pipe)) < 0)
+		if (wait_event_freezable_exclusive(pipe->rd_wait, pipe_readable(pipe)) < 0)
 			return -ERESTARTSYS;
 
 		wake_next_reader = true;
@@ -1098,7 +1098,7 @@ static int wait_for_partner(struct pipe_inode_info *pipe, unsigned int *cnt)
 	int cur = *cnt;
 
 	while (cur == *cnt) {
-		prepare_to_wait(&pipe->rd_wait, &rdwait, TASK_INTERRUPTIBLE);
+		prepare_to_wait(&pipe->rd_wait, &rdwait, TASK_INTERRUPTIBLE | TASK_FREEZABLE);
 		pipe_unlock(pipe);
 		schedule();
 		finish_wait(&pipe->rd_wait, &rdwait);
-- 
2.25.1

[PATCH v1 4/5] fuse: Add TASK_FREEZABLE to device read operations

[Dai Junbing]

Add the TASK_FREEZABLE flag when sleeping during FUSE device read
operations. This prevents premature wakeups during system suspend/resume
cycles, avoiding unnecessary wakeup overhead and power consumption.

During sleep in the FUSE device read path, no kernel locks are held.
Therefore, adding TASK_FREEZABLE is safe.

Signed-off-by: Dai Junbing <daijunbing@vivo.com>
---
 fs/fuse/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index e80cd8f2c049..b3dbd113e2e2 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1418,7 +1418,7 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
 
 		if (file->f_flags & O_NONBLOCK)
 			return -EAGAIN;
-		err = wait_event_interruptible_exclusive(fiq->waitq,
+		err = wait_event_freezable_exclusive(fiq->waitq,
 				!fiq->connected || request_pending(fiq));
 		if (err)
 			return err;
-- 
2.25.1

[PATCH v1 5/5] jbd2: Add TASK_FREEZABLE to kjournald2 thread

[Dai Junbing]

Set the TASK_FREEZABLE flag when the kjournald2 kernel thread sleeps
during journal commit operations. This prevents premature wakeups
during system suspend/resume cycles, avoiding unnecessary CPU wakeups
and power consumption.

in this case, the original code:

	prepare_to_wait(&journal->j_wait_commit, &wait,
               	 TASK_INTERRUPTIBLE);
	if (journal->j_commit_sequence != journal->j_commit_request)
        	should_sleep = 0;

	transaction = journal->j_running_transaction;
	if (transaction && time_after_eq(jiffies, transaction->t_expires))
        	should_sleep = 0;
	......
	......
	if (should_sleep) {
        	write_unlock(&journal->j_state_lock);
        	schedule();
        	write_lock(&journal->j_state_lock);
	}

is functionally equivalent to the more concise:

	write_unlock(&journal->j_state_lock);
	wait_event_freezable_exclusive(&journal->j_wait_commit,
        	journal->j_commit_sequence == journal->j_commit_request ||
        	(journal->j_running_transaction &&
         	time_after_eq(jiffies, transaction->t_expires)) ||
        	(journal->j_flags & JBD2_UNMOUNT));
	write_lock(&journal->j_state_lock);

Signed-off-by: Dai Junbing <daijunbing@vivo.com>
---
 fs/jbd2/journal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index d480b94117cd..9a1def9f730b 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -222,7 +222,7 @@ static int kjournald2(void *arg)
 		DEFINE_WAIT(wait);
 
 		prepare_to_wait(&journal->j_wait_commit, &wait,
-				TASK_INTERRUPTIBLE);
+				TASK_INTERRUPTIBLE | TASK_FREEZABLE);
 		transaction = journal->j_running_transaction;
 		if (transaction == NULL ||
 		    time_before(jiffies, transaction->t_expires)) {
-- 
2.25.1

Re: [PATCH v1 5/5] jbd2: Add TASK_FREEZABLE to kjournald2 thread

[Jan Kara]

On Wed 30-07-25 09:47:06, Dai Junbing wrote:
> Set the TASK_FREEZABLE flag when the kjournald2 kernel thread sleeps
> during journal commit operations. This prevents premature wakeups
> during system suspend/resume cycles, avoiding unnecessary CPU wakeups
> and power consumption.
> 
> in this case, the original code:
> 
> 	prepare_to_wait(&journal->j_wait_commit, &wait,
>                	 TASK_INTERRUPTIBLE);
> 	if (journal->j_commit_sequence != journal->j_commit_request)
>         	should_sleep = 0;
> 
> 	transaction = journal->j_running_transaction;
> 	if (transaction && time_after_eq(jiffies, transaction->t_expires))
>         	should_sleep = 0;
> 	......
> 	......
> 	if (should_sleep) {
>         	write_unlock(&journal->j_state_lock);
>         	schedule();
>         	write_lock(&journal->j_state_lock);
> 	}
> 
> is functionally equivalent to the more concise:
> 
> 	write_unlock(&journal->j_state_lock);
> 	wait_event_freezable_exclusive(&journal->j_wait_commit,
>         	journal->j_commit_sequence == journal->j_commit_request ||
>         	(journal->j_running_transaction &&
>          	time_after_eq(jiffies, transaction->t_expires)) ||
>         	(journal->j_flags & JBD2_UNMOUNT));
> 	write_lock(&journal->j_state_lock);

This would be actually wrong because you cannot safely do some of the
dereferences without holding j_state_lock. Luckily you didn't modify the
existing code in the patch, just the changelog is bogus so please fix it.

> Signed-off-by: Dai Junbing <daijunbing@vivo.com>
> ---
>  fs/jbd2/journal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index d480b94117cd..9a1def9f730b 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -222,7 +222,7 @@ static int kjournald2(void *arg)
>  		DEFINE_WAIT(wait);
>  
>  		prepare_to_wait(&journal->j_wait_commit, &wait,
> -				TASK_INTERRUPTIBLE);
> +				TASK_INTERRUPTIBLE | TASK_FREEZABLE);

So this looks fine but I have one question. There's code like:

        if (freezing(current)) {
                /*
                 * The simpler the better. Flushing journal isn't a
                 * good idea, because that depends on threads that may
                 * be already stopped.
                 */
                jbd2_debug(1, "Now suspending kjournald2\n");
                write_unlock(&journal->j_state_lock);
                try_to_freeze();
                write_lock(&journal->j_state_lock);

a few lines above. Is it still needed after your change? I guess that
probably yes (e.g. when the freeze attempt happens while kjournald still
performs some work then the later schedule in TASK_FREEZABLE state doesn't
necessarily freeze the kthread). But getting a confirmation would be nice.

								Honza

>  		transaction = journal->j_running_transaction;
>  		if (transaction == NULL ||
>  		    time_before(jiffies, transaction->t_expires)) {
> -- 
> 2.25.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v1 5/5] jbd2: Add TASK_FREEZABLE to kjournald2 thread

[daijunbing]

在 2025/7/30 18:52, Jan Kara 写道:
> On Wed 30-07-25 09:47:06, Dai Junbing wrote:
>> Set the TASK_FREEZABLE flag when the kjournald2 kernel thread sleeps
>> during journal commit operations. This prevents premature wakeups
>> during system suspend/resume cycles, avoiding unnecessary CPU wakeups
>> and power consumption.
>>
>> in this case, the original code:
>>
>> 	prepare_to_wait(&journal->j_wait_commit, &wait,
>>                 	 TASK_INTERRUPTIBLE);
>> 	if (journal->j_commit_sequence != journal->j_commit_request)
>>          	should_sleep = 0;
>>
>> 	transaction = journal->j_running_transaction;
>> 	if (transaction && time_after_eq(jiffies, transaction->t_expires))
>>          	should_sleep = 0;
>> 	......
>> 	......
>> 	if (should_sleep) {
>>          	write_unlock(&journal->j_state_lock);
>>          	schedule();
>>          	write_lock(&journal->j_state_lock);
>> 	}
>>
>> is functionally equivalent to the more concise:
>>
>> 	write_unlock(&journal->j_state_lock);
>> 	wait_event_freezable_exclusive(&journal->j_wait_commit,
>>          	journal->j_commit_sequence == journal->j_commit_request ||
>>          	(journal->j_running_transaction &&
>>           	time_after_eq(jiffies, transaction->t_expires)) ||
>>          	(journal->j_flags & JBD2_UNMOUNT));
>> 	write_lock(&journal->j_state_lock);
> 
> This would be actually wrong because you cannot safely do some of the
> dereferences without holding j_state_lock. Luckily you didn't modify the
> existing code in the patch, just the changelog is bogus so please fix it.

Thank you for pointing this out. I'll make the corresponding changelog 
updates.

> 
>> Signed-off-by: Dai Junbing <daijunbing@vivo.com>
>> ---
>>   fs/jbd2/journal.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
>> index d480b94117cd..9a1def9f730b 100644
>> --- a/fs/jbd2/journal.c
>> +++ b/fs/jbd2/journal.c
>> @@ -222,7 +222,7 @@ static int kjournald2(void *arg)
>>   		DEFINE_WAIT(wait);
>>   
>>   		prepare_to_wait(&journal->j_wait_commit, &wait,
>> -				TASK_INTERRUPTIBLE);
>> +				TASK_INTERRUPTIBLE | TASK_FREEZABLE);
> 
> So this looks fine but I have one question. There's code like:
> 
>          if (freezing(current)) {
>                  /*
>                   * The simpler the better. Flushing journal isn't a
>                   * good idea, because that depends on threads that may
>                   * be already stopped.
>                   */
>                  jbd2_debug(1, "Now suspending kjournald2\n");
>                  write_unlock(&journal->j_state_lock);
>                  try_to_freeze();
>                  write_lock(&journal->j_state_lock);
> 
> a few lines above. Is it still needed after your change? I guess that
> probably yes (e.g. when the freeze attempt happens while kjournald still
> performs some work then the later schedule in TASK_FREEZABLE state doesn't
> necessarily freeze the kthread). But getting a confirmation would be nice.

I agree with your perspective.
While cleaner implementations may exist,I haven't made changes due to 
uncertainty about the alternatives>
> 								Honza
> 
>>   		transaction = journal->j_running_transaction;
>>   		if (transaction == NULL ||
>>   		    time_before(jiffies, transaction->t_expires)) {
>> -- 
>> 2.25.1
>>