From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH CI 1/2] Revert "freezer, sched: Rewrite core freezer logic fix"
Date: Fri, 4 Nov 2022 14:04:01 +0200 [thread overview]
Message-ID: <20221104120402.5677-1-ville.syrjala@linux.intel.com> (raw)
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
This reverts commit f3387d5883ad92e9a54306fa3dff97d4f0581d78.
---
kernel/sched/core.c | 49 ++++++++++++++++-----------------------------
1 file changed, 17 insertions(+), 32 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f519f44cd4c7..cb2aa2b54c7a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4200,37 +4200,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
return success;
}
-static bool __task_needs_rq_lock(struct task_struct *p)
-{
- unsigned int state = READ_ONCE(p->__state);
-
- /*
- * Since pi->lock blocks try_to_wake_up(), we don't need rq->lock when
- * the task is blocked. Make sure to check @state since ttwu() can drop
- * locks at the end, see ttwu_queue_wakelist().
- */
- if (state == TASK_RUNNING || state == TASK_WAKING)
- return true;
-
- /*
- * Ensure we load p->on_rq after p->__state, otherwise it would be
- * possible to, falsely, observe p->on_rq == 0.
- *
- * See try_to_wake_up() for a longer comment.
- */
- smp_rmb();
- if (p->on_rq)
- return true;
-
-#ifdef CONFIG_SMP
- smp_rmb();
- if (p->on_cpu)
- return true;
-#endif
-
- return false;
-}
-
/**
* task_call_func - Invoke a function on task in fixed state
* @p: Process for which the function is to be invoked, can be @current.
@@ -4248,12 +4217,28 @@ static bool __task_needs_rq_lock(struct task_struct *p)
int task_call_func(struct task_struct *p, task_call_f func, void *arg)
{
struct rq *rq = NULL;
+ unsigned int state;
struct rq_flags rf;
int ret;
raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
- if (__task_needs_rq_lock(p))
+ state = READ_ONCE(p->__state);
+
+ /*
+ * Ensure we load p->on_rq after p->__state, otherwise it would be
+ * possible to, falsely, observe p->on_rq == 0.
+ *
+ * See try_to_wake_up() for a longer comment.
+ */
+ smp_rmb();
+
+ /*
+ * Since pi->lock blocks try_to_wake_up(), we don't need rq->lock when
+ * the task is blocked. Make sure to check @state since ttwu() can drop
+ * locks at the end, see ttwu_queue_wakelist().
+ */
+ if (state == TASK_RUNNING || state == TASK_WAKING || p->on_rq)
rq = __task_rq_lock(p, &rf);
/*
--
2.37.4
next reply other threads:[~2022-11-04 12:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 12:04 Ville Syrjala [this message]
2022-11-04 12:04 ` [Intel-gfx] [PATCH CI 2/2] freezer, sched: Rewrite core freezer logic v2 Ville Syrjala
2022-11-04 12:40 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [CI,1/2] Revert "freezer, sched: Rewrite core freezer logic fix" Patchwork
2022-11-04 13:02 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-11-05 1:13 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=20221104120402.5677-1-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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