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 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.