From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: 'Peter Zijlstra' <peterz@infradead.org>,
'LKML' <linux-kernel@vger.kernel.org>,
'Daniel Lezcano' <daniel.lezcano@linaro.org>,
'Linux PM' <linux-pm@vger.kernel.org>
Subject: RE: [PATCH] cpuidle: poll_state: Revise loop termination condition
Date: Sat, 10 Nov 2018 13:50:01 -0800 [thread overview]
Message-ID: <001101d4793f$56535770$02fa0650$@net> (raw)
In-Reply-To: 7Sblgyz0iivID7SbmgCnar
On 2018.10.02 14:51 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> If need_resched() returns "false", breaking out of the loop in
> poll_idle() will cause a new idle state to be selected, so in fact
> usually it doesn't make sense to spin in it longer than the target
> residency of the second state. [Note that the "polling" state is
> used only if there is at least one "real" state defined in addition
> to it.] On the other hand, breaking out of it early (say in case
> the next state is disabled) shouldn't hurt as it is polling anyway.
While I agree that it is polling anyway, this change can add significant
burden when debugging and trace is enabled for cpu_idle, if idle state 0
is used often.
For example: Phoronix dbench test, 96 clients: 900 second trace:
Kernel 4.20-rc1:
idle state 0 entry exits: 686,724
Does trace being enabled effect the system under test: Yes.
Kernel 4.20-rc1 with this patch reverted:
idle state 0 entry exits: 66,185
Does trace being enabled effect the system under test: No, or minimal.
... Doug
next reply other threads:[~2018-11-10 21:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 21:50 Doug Smythies [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-10-02 21:50 [PATCH] cpuidle: poll_state: Revise loop termination condition Rafael J. Wysocki
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='001101d4793f$56535770$02fa0650$@net' \
--to=dsmythies@telus.net \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--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 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.