All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nam Cao <namcao@linutronix.de>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Tomas Glozar <tglozar@redhat.com>, Juri Lelli <jlelli@redhat.com>
Subject: Re: [RFC PATCH 6/9] sched: Treat try_to_block_task with pending signal as wakeup
Date: Sun, 13 Apr 2025 17:05:40 +0200	[thread overview]
Message-ID: <20250413150540.3ZW7XJVs@linutronix.de> (raw)
In-Reply-To: <20250404084512.98552-17-gmonaco@redhat.com>

On Fri, Apr 04, 2025 at 10:45:19AM +0200, Gabriele Monaco wrote:
> If a task sets itself to interruptible and schedules, the __schedule
> function checks whether there's a pending signal and, if that's the
> case, updates the state of the task to runnable instead of dequeuing.
> By looking at the tracepoints, we see the task enters the scheduler
> while sleepable but exits as runnable. From a modelling perspective,
> this is equivalent to a wakeup and the tracepoints should reflect that.
> 
> Add the waking/wakeup tracepoints in the try_to_block_task function and
> set the prev_state used by the sched_switch tracepoint to TASK_RUNNING
> if the task had a pending signal and was not blocked.
> 
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
>  kernel/sched/core.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f2f79236d5811..48cb32abce01a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6584,7 +6584,12 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
>  	int flags = DEQUEUE_NOCLOCK;
>  
>  	if (signal_pending_state(task_state, p)) {
> -		WRITE_ONCE(p->__state, TASK_RUNNING);
> +		/*
> +		 * From a modelling perspective, this is equivalent to a wakeup
> +		 * before dequeuing the task: trace accordingly.
> +		 */
> +		trace_sched_waking(p);
> +		ttwu_do_wakeup(p);

I don't think we should put trace_sched_waking() here. trace_sched_waking()
"is guaranteed to be called from the waking context", and this is not the
waking context.

There is already a trace_sched_waking() in signal_wake_up_state(). This is
duplicating that, in the wrong context.

ttwu_do_wakeup() alone should be sufficient?

Best regards,
Nam

  reply	other threads:[~2025-04-13 15:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04  8:45 [RFC PATCH 0/9] rv: Add monitors to validate task switch Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 1/9] tools/rv: Do not skip idle in trace Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 2/9] tools/rv: Stop gracefully also on SIGTERM Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 3/9] rv: Add da_handle_start_run_event_ to per-task monitors Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 4/9] rv: Remove trailing whitespace from tracepoint string Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 5/9] sched: Add sched tracepoints for RV task model Gabriele Monaco
2025-04-05  3:25   ` kernel test robot
2025-04-05  5:21   ` kernel test robot
2025-04-04  8:45 ` [RFC PATCH 6/9] sched: Treat try_to_block_task with pending signal as wakeup Gabriele Monaco
2025-04-13 15:05   ` Nam Cao [this message]
2025-04-14 10:31     ` Gabriele Monaco
2025-04-15 11:04       ` Nam Cao
2025-04-15 11:30         ` Gabriele Monaco
2025-04-16  9:20           ` Nam Cao
2025-04-16 11:42             ` Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 7/9] rv: Retry when da monitor detects race conditions Gabriele Monaco
2025-04-11  4:52   ` Nam Cao
2025-04-11  6:09     ` Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 8/9] rv: Replace tss monitor with more complete sts Gabriele Monaco
2025-04-04  8:45 ` [RFC PATCH 9/9] rv: Add srs per-task monitor Gabriele Monaco
2025-04-10  8:53   ` Juri Lelli
2025-04-11  6:12     ` Gabriele Monaco

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=20250413150540.3ZW7XJVs@linutronix.de \
    --to=namcao@linutronix.de \
    --cc=gmonaco@redhat.com \
    --cc=jlelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglozar@redhat.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.