Re: [PATCH] sched,rt,nohz: stop scheduler tick if running realtime task
On Mon, Feb 16, 2015 at 03:23:49PM -0500, Rik van Riel wrote:
> If the CPU is running a realtime task that does not round-robin with
> another realtime task of equal priority, there is no point in keeping
> the scheduler tick going. After all, whenever the scheduler tick runs,
> the kernel will just decide not to reschedule.
>
> Extend sched_can_stop_tick to recognize these situations, and inform
> the rest of the kernel that the scheduler tick can be stopped.
>
> Signed-off-by: Rik van Riel
> Tested-by: Luiz Capitulino
> ---
> kernel/sched/core.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index ade2958a9197..ad985a632c4d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
> bool sched_can_stop_tick(void)
> {
> /*
> + * FIFO realtime policy runs the highest priority task. Other runnable
> + * tasks are of a lower priority. The scheduler tick does nothing.
> + */
> + if (current->policy == SCHED_FIFO)
> + return true;
> +
> + /*
> + * Round-robin realtime tasks time slice with other tasks at the same
> + * realtime priority. Is this task the only one at this priority?
> + */
> + if (current->policy == SCHED_RR) {
> + struct sched_rt_entity *rt_se = >rt;
> + return rt_se->run_list.prev == rt_se->run_list.next;
> + }
> +
> + /*
I think it should work yes.
There are still many things, that the tick updates, which are broken without it
(rq->rt_avg is supposed to be updated avery tick for example) but it goes way
beyond
the scope of this change since SCHED_FIFO tasks are already allowed to stop the
tick
when no SCHED_OTHER task is running so the problem is there already before this
patch.
So it's a welcome fix, thanks.
>* More than one running task need preemption.
>* nr_running update is assumed to be visible
>* after IPI is sent from wakers.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched,rt,nohz: stop scheduler tick if running realtime task
On Mon, Feb 16, 2015 at 03:23:49PM -0500, Rik van Riel wrote:
If the CPU is running a realtime task that does not round-robin with
another realtime task of equal priority, there is no point in keeping
the scheduler tick going. After all, whenever the scheduler tick runs,
the kernel will just decide not to reschedule.
Extend sched_can_stop_tick to recognize these situations, and inform
the rest of the kernel that the scheduler tick can be stopped.
Signed-off-by: Rik van Riel r...@redhat.com
Tested-by: Luiz Capitulino lcapitul...@redhat.com
---
kernel/sched/core.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ade2958a9197..ad985a632c4d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
bool sched_can_stop_tick(void)
{
/*
+ * FIFO realtime policy runs the highest priority task. Other runnable
+ * tasks are of a lower priority. The scheduler tick does nothing.
+ */
+ if (current-policy == SCHED_FIFO)
+ return true;
+
+ /*
+ * Round-robin realtime tasks time slice with other tasks at the same
+ * realtime priority. Is this task the only one at this priority?
+ */
+ if (current-policy == SCHED_RR) {
+ struct sched_rt_entity *rt_se = current-rt;
+ return rt_se-run_list.prev == rt_se-run_list.next;
+ }
+
+ /*
I think it should work yes.
There are still many things, that the tick updates, which are broken without it
(rq-rt_avg is supposed to be updated avery tick for example) but it goes way
beyond
the scope of this change since SCHED_FIFO tasks are already allowed to stop the
tick
when no SCHED_OTHER task is running so the problem is there already before this
patch.
So it's a welcome fix, thanks.
* More than one running task need preemption.
* nr_running update is assumed to be visible
* after IPI is sent from wakers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched,rt,nohz: stop scheduler tick if running realtime task
If the CPU is running a realtime task that does not round-robin with
another realtime task of equal priority, there is no point in keeping
the scheduler tick going. After all, whenever the scheduler tick runs,
the kernel will just decide not to reschedule.
Extend sched_can_stop_tick to recognize these situations, and inform
the rest of the kernel that the scheduler tick can be stopped.
Signed-off-by: Rik van Riel
Tested-by: Luiz Capitulino
---
kernel/sched/core.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ade2958a9197..ad985a632c4d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
bool sched_can_stop_tick(void)
{
/*
+* FIFO realtime policy runs the highest priority task. Other runnable
+* tasks are of a lower priority. The scheduler tick does nothing.
+*/
+ if (current->policy == SCHED_FIFO)
+ return true;
+
+ /*
+* Round-robin realtime tasks time slice with other tasks at the same
+* realtime priority. Is this task the only one at this priority?
+*/
+ if (current->policy == SCHED_RR) {
+ struct sched_rt_entity *rt_se = >rt;
+ return rt_se->run_list.prev == rt_se->run_list.next;
+ }
+
+ /*
* More than one running task need preemption.
* nr_running update is assumed to be visible
* after IPI is sent from wakers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched,rt,nohz: stop scheduler tick if running realtime task
If the CPU is running a realtime task that does not round-robin with
another realtime task of equal priority, there is no point in keeping
the scheduler tick going. After all, whenever the scheduler tick runs,
the kernel will just decide not to reschedule.
Extend sched_can_stop_tick to recognize these situations, and inform
the rest of the kernel that the scheduler tick can be stopped.
Signed-off-by: Rik van Riel r...@redhat.com
Tested-by: Luiz Capitulino lcapitul...@redhat.com
---
kernel/sched/core.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ade2958a9197..ad985a632c4d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
bool sched_can_stop_tick(void)
{
/*
+* FIFO realtime policy runs the highest priority task. Other runnable
+* tasks are of a lower priority. The scheduler tick does nothing.
+*/
+ if (current-policy == SCHED_FIFO)
+ return true;
+
+ /*
+* Round-robin realtime tasks time slice with other tasks at the same
+* realtime priority. Is this task the only one at this priority?
+*/
+ if (current-policy == SCHED_RR) {
+ struct sched_rt_entity *rt_se = current-rt;
+ return rt_se-run_list.prev == rt_se-run_list.next;
+ }
+
+ /*
* More than one running task need preemption.
* nr_running update is assumed to be visible
* after IPI is sent from wakers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
