From: Uladzislau Rezki <urezki@gmail.com>
To: Zqiang <qiang1.zhang@intel.com>
Cc: paulmck@kernel.org, frederic@kernel.org,
quic_neeraju@quicinc.com, josh@joshtriplett.org,
urezki@gmail.com, bigeasy@linutronix.de, juri.lelli@redhat.com,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rcu: Only boost rcu reader tasks with lower priority than boost kthreads
Date: Thu, 10 Mar 2022 19:27:19 +0100 [thread overview]
Message-ID: <YipDBx137UdsieWV@pc638.lan> (raw)
In-Reply-To: <20220309081523.348450-1-qiang1.zhang@intel.com>
> When RCU_BOOST is enabled, the boost kthreads will boosting readers
> who are blocking a given grace period, if the current reader tasks
> have a higher priority than boost kthreads(the boost kthreads priority
> not always 1, if the kthread_prio is set), boosting is useless, skip
> current task and select next task to boosting, reduce the time for a
> given grace period.
>
> Signed-off-by: Zqiang <qiang1.zhang@intel.com>
> ---
> v1->v2:
> rename label 'end' to 'skip_boost'.
> add 'boost_exp_tasks' pointer to point 'rnp->exp_tasks'
> do the similar thing as normal grace period.
>
> kernel/rcu/tree.h | 2 ++
> kernel/rcu/tree_plugin.h | 31 +++++++++++++++++++++++--------
> 2 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index b8d07bf92d29..862ca09b56c7 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -103,6 +103,8 @@ struct rcu_node {
> /* queued on this rcu_node structure that */
> /* are blocking the current grace period, */
> /* there can be no such task. */
> + struct list_head *boost_exp_tasks;
> +
> struct rt_mutex boost_mtx;
> /* Used only for the priority-boosting */
> /* side effect, not as a lock. */
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index c3d212bc5338..22bf5a8040f5 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -12,6 +12,7 @@
> */
>
> #include "../locking/rtmutex_common.h"
> +#include <linux/sched/deadline.h>
>
> static bool rcu_rdp_is_offloaded(struct rcu_data *rdp)
> {
> @@ -535,6 +536,8 @@ rcu_preempt_deferred_qs_irqrestore(struct task_struct *t, unsigned long flags)
> drop_boost_mutex = rt_mutex_owner(&rnp->boost_mtx.rtmutex) == t;
> if (&t->rcu_node_entry == rnp->boost_tasks)
> WRITE_ONCE(rnp->boost_tasks, np);
> + if (&t->rcu_node_entry == rnp->boost_exp_tasks)
> + WRITE_ONCE(rnp->boost_exp_tasks, np);
> }
>
> /*
> @@ -1022,7 +1025,7 @@ static int rcu_boost(struct rcu_node *rnp)
> struct task_struct *t;
> struct list_head *tb;
>
> - if (READ_ONCE(rnp->exp_tasks) == NULL &&
> + if (READ_ONCE(rnp->boost_exp_tasks) == NULL &&
> READ_ONCE(rnp->boost_tasks) == NULL)
> return 0; /* Nothing left to boost. */
>
> @@ -1032,7 +1035,7 @@ static int rcu_boost(struct rcu_node *rnp)
> * Recheck under the lock: all tasks in need of boosting
> * might exit their RCU read-side critical sections on their own.
> */
> - if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL) {
> + if (rnp->boost_exp_tasks == NULL && rnp->boost_tasks == NULL) {
> raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> return 0;
> }
> @@ -1043,8 +1046,8 @@ static int rcu_boost(struct rcu_node *rnp)
> * expedited grace period must boost all blocked tasks, including
> * those blocking the pre-existing normal grace period.
> */
> - if (rnp->exp_tasks != NULL)
> - tb = rnp->exp_tasks;
> + if (rnp->boost_exp_tasks != NULL)
> + tb = rnp->boost_exp_tasks;
> else
> tb = rnp->boost_tasks;
>
> @@ -1065,14 +1068,24 @@ static int rcu_boost(struct rcu_node *rnp)
> * section.
> */
> t = container_of(tb, struct task_struct, rcu_node_entry);
> + if (dl_task(t) || t->prio <= current->prio) {
This is a bit confusing to me. We know that "current" has SCHED_FIFO
class. In this scenario if "t->prio" has lower value(higher priority)
the task falls into all real-time categories anyway and is either:
- SCHED_FIFO
- SCHED_RR
- SCHED_DEADLINE
Checking whether the task is dl_task() sounds like unnecessary there.
Am i missing something? Could you please comment on it?
Thanks!
--
Vlad Rezki
next prev parent reply other threads:[~2022-03-10 18:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 8:15 [PATCH v2] rcu: Only boost rcu reader tasks with lower priority than boost kthreads Zqiang
2022-03-10 18:27 ` Uladzislau Rezki [this message]
2022-03-11 1:53 ` Zhang, Qiang1
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=YipDBx137UdsieWV@pc638.lan \
--to=urezki@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=frederic@kernel.org \
--cc=josh@joshtriplett.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=qiang1.zhang@intel.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.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