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: Tue, 15 Apr 2025 13:04:55 +0200 [thread overview]
Message-ID: <20250415110455.0Qj-4EN2@linutronix.de> (raw)
In-Reply-To: <fb998d03b4ecc51834bf4383a71932ca877900cd.camel@redhat.com>
On Mon, Apr 14, 2025 at 12:31:12PM +0200, Gabriele Monaco wrote:
> Mmh, that's a good point.
> The thing is: this happens when the signal is generated while we are
> scheduling (on different CPUs), so we take a short-cut and put the task
> to running directly.
> This thing is already racy, so we may or may not see the waking/wakeup.
>
> Now probably waking shouldn't be there for the reason you said, but I'm
> not sure a wakeup not following a waking would be correct either.
> I might be missing something here, though.
I'm not familiar with signal and sched, so I don't have anything more to
add, sorry.
I presume this is to make the srs monitor works? Perhaps it is possible to
modify the model so that this patch is not required? Let me stare at srs,
maybe I will have something..
Nam
next prev parent reply other threads:[~2025-04-15 11:05 UTC|newest]
Thread overview: 20+ 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-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
2025-04-14 10:31 ` Gabriele Monaco
2025-04-15 11:04 ` Nam Cao [this message]
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=20250415110455.0Qj-4EN2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox