From: Pavan Kondeti <pkondeti@codeaurora.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH] kernel/sched/core: busy wait before going idle
Date: Mon, 23 Apr 2018 15:47:40 +0530 [thread overview]
Message-ID: <20180423101740.GA28936@codeaurora.org> (raw)
In-Reply-To: <20180415133149.24112-1-npiggin@gmail.com>
Hi Nick,
On Sun, Apr 15, 2018 at 11:31:49PM +1000, Nicholas Piggin wrote:
> This is a quick hack for comments, but I've always wondered --
> if we have a short term polling idle states in cpuidle for performance
> -- why not skip the context switch and entry into all the idle states,
> and just wait for a bit to see if something wakes up again.
>
> It's not uncommon to see various going-to-idle work in kernel profiles.
> This might be a way to reduce that (and just the cost of switching
> registers and kernel stack to idle thread). This can be an important
> path for single thread request-response throughput.
>
> tbench bandwidth seems to be improved (the numbers aren't too stable
> but they pretty consistently show some gain). 10-20% would be a pretty
> nice gain for such workloads
>
> clients 1 2 4 8 16 128
> vanilla 232 467 823 1819 3218 9065
> patched 310 503 962 2465 3743 9820
>
<snip>
> +idle_spin_end:
> /* Promote REQ to ACT */
> rq->clock_update_flags <<= 1;
> update_rq_clock(rq);
> @@ -3437,6 +3439,32 @@ static void __sched notrace __schedule(bool preempt)
> if (unlikely(signal_pending_state(prev->state, prev))) {
> prev->state = TASK_RUNNING;
> } else {
> + /*
> + * Busy wait before switching to idle thread. This
> + * is marked unlikely because we're idle so jumping
> + * out of line doesn't matter too much.
> + */
> + if (unlikely(do_idle_spin && rq->nr_running == 1)) {
> + u64 start;
> +
> + do_idle_spin = false;
> +
> + rq->clock_update_flags &= ~(RQCF_ACT_SKIP|RQCF_REQ_SKIP);
> + rq_unlock_irq(rq, &rf);
> +
> + spin_begin();
> + start = local_clock();
> + while (!need_resched() && prev->state &&
> + !signal_pending_state(prev->state, prev)) {
> + spin_cpu_relax();
> + if (local_clock() - start > 1000000)
> + break;
> + }
Couple of comments/questions.
When a RT task is doing this busy loop,
(1) need_resched() may not be set even if a fair/normal task is enqueued on
this CPU.
(2) Any lower prio RT task waking up on this CPU may migrate to another CPU
thinking this CPU is busy with higher prio RT task.
> + spin_end();
> +
> + rq_lock_irq(rq, &rf);
> + goto idle_spin_end;
> + }
> deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK);
> prev->on_rq = 0;
>
> --
> 2.17.0
>
Thanks,
Pavan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2018-04-23 10:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-15 13:31 [RFC PATCH] kernel/sched/core: busy wait before going idle Nicholas Piggin
2018-04-20 7:44 ` Peter Zijlstra
2018-04-20 9:01 ` Nicholas Piggin
2018-04-20 10:58 ` Peter Zijlstra
2018-04-20 12:28 ` Nicholas Piggin
2018-04-23 10:17 ` Pavan Kondeti [this message]
2018-04-24 5:26 ` Nicholas Piggin
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=20180423101740.GA28936@codeaurora.org \
--to=pkondeti@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=npiggin@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/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