Re: [RFT][PATCH v7.3 5/8] cpuidle: Return nohz hint from cpuidle_select()

However my fundamental concerns about the policy whether to disable the sched tick remain: Mixing the precise timer and vague heuristic for the decision is dangerous. The timer should not be wrong, heuristic may be. Well, I wouldn't say "dangerous". It may be suboptimal, but even that is not

Re: [RFT][PATCH v7.3 5/8] cpuidle: Return nohz hint from cpuidle_select()

However my fundamental concerns about the policy whether to disable the sched tick remain: Mixing the precise timer and vague heuristic for the decision is dangerous. The timer should not be wrong, heuristic may be. Well, I wouldn't say "dangerous". It may be suboptimal, but even that is not

Re: [PATCH v9 00/10] sched/cpuidle: Idle loop rework

On 2018-04-08 18:32, Rafael J. Wysocki wrote: The v9 along with some cleanups suggested by Frederic on top of it and with ACKs from Peter (obtained on IRC) is now available from the pm-cpuidle branch in the linux-pm.git tree. It has been added to my linux-next branch, so it probably will be

Re: [PATCH v9 00/10] sched/cpuidle: Idle loop rework

On 2018-04-08 18:32, Rafael J. Wysocki wrote: The v9 along with some cleanups suggested by Frederic on top of it and with ACKs from Peter (obtained on IRC) is now available from the pm-cpuidle branch in the linux-pm.git tree. It has been added to my linux-next branch, so it probably will be

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-28 12:56, Rafael J. Wysocki wrote: On Wed, Mar 28, 2018 at 12:37 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: On Wed, Mar 28, 2018 at 10:38 AM, Thomas Ilsche <thomas.ils...@tu-dresden.de> wrote: On 2018-03-28 10:13, Rafael J. Wysocki wrote: [cut] So I do $ fo

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-28 12:56, Rafael J. Wysocki wrote: On Wed, Mar 28, 2018 at 12:37 PM, Rafael J. Wysocki wrote: On Wed, Mar 28, 2018 at 10:38 AM, Thomas Ilsche wrote: On 2018-03-28 10:13, Rafael J. Wysocki wrote: [cut] So I do $ for cpu in 0 1 2 3; do taskset -c $cpu sh -c 'while true; do

Re: [RFT][PATCH v7.3 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-22 18:40, Rafael J. Wysocki wrote: From: Rafael J. Wysocki Add a new pointer argument to cpuidle_select() and to the ->select cpuidle governor callback to allow a boolean value indicating whether or not the tick should be stopped before entering the

Re: [RFT][PATCH v7.3 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-22 18:40, Rafael J. Wysocki wrote: From: Rafael J. Wysocki Add a new pointer argument to cpuidle_select() and to the ->select cpuidle governor callback to allow a boolean value indicating whether or not the tick should be stopped before entering the selected state to be returned

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-28 10:13, Rafael J. Wysocki wrote: On Wed, Mar 28, 2018 at 12:10 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: On Tuesday, March 27, 2018 11:50:02 PM CEST Thomas Ilsche wrote: On 2018-03-20 16:45, Rafael J. Wysocki wrote: From: Rafael J. Wysocki <rafael.j.wyso...@

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-28 10:13, Rafael J. Wysocki wrote: On Wed, Mar 28, 2018 at 12:10 AM, Rafael J. Wysocki wrote: On Tuesday, March 27, 2018 11:50:02 PM CEST Thomas Ilsche wrote: On 2018-03-20 16:45, Rafael J. Wysocki wrote: From: Rafael J. Wysocki In order to address the issue with short idle

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-20 16:45, Rafael J. Wysocki wrote: From: Rafael J. Wysocki In order to address the issue with short idle duration predictions by the idle governor after the tick has been stopped, reorder the code in cpuidle_idle_call() so that the governor idle state

Re: [RFT][PATCH v7 6/8] sched: idle: Select idle state before stopping the tick

On 2018-03-20 16:45, Rafael J. Wysocki wrote: From: Rafael J. Wysocki In order to address the issue with short idle duration predictions by the idle governor after the tick has been stopped, reorder the code in cpuidle_idle_call() so that the governor idle state selection runs before

Re: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-21 23:15, Rafael J. Wysocki wrote: On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche <thomas.ils...@tu-dresden.de> wrote: On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of it:https://patchwork.kernel.org

Re: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-21 23:15, Rafael J. Wysocki wrote: On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche wrote: On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of it:https://patchwork.kernel.org/patch/10299429/ The current

Re: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of it:https://patchwork.kernel.org/patch/10299429/ The current versions (including the above) is in the git branch at

Re: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()

On 2018-03-21 15:36, Rafael J. Wysocki wrote: So please disregard this one entirely and take the v7.2 replacement instead of it:https://patchwork.kernel.org/patch/10299429/ The current versions (including the above) is in the git branch at

Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

predicts idle duration within the tick period range and the idea here is to do that when the selected state is the deepest available one with the target residency within the tick period range. This allows the opportunity to save more energy to be seized which balances the extra overhead of stopping

Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

the idea here is to do that when the selected state is the deepest available one with the target residency within the tick period range. This allows the opportunity to save more energy to be seized which balances the extra overhead of stopping the tick. HTH -- Dipl. Inf. Thomas Ilsche Computer Scientist Hig

Re: [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick

On 2018-03-15 23:19, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If the scheduler tick has been stopped already and the governor selects a shallow idle state, the CPU can spend a long time in that state if the selection is based on an inaccurate prediction of

Re: [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick

On 2018-03-15 23:19, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If the scheduler tick has been stopped already and the governor selects a shallow idle state, the CPU can spend a long time in that state if the selection is based on an inaccurate prediction of idle time. That effect turns

Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

and the already selected state may not fit before the next tick time. Patch 7 Deals with the situation in which the tick was stopped previously, but the idle governor still predicts short idle. This series is complementary to the poll_idle() patch at https://patchwork.kernel.org/patch/10282237/ Th

Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

and the already selected state may not fit before the next tick time. Patch 7 Deals with the situation in which the tick was stopped previously, but the idle governor still predicts short idle. This series is complementary to the poll_idle() patch at https://patchwork.kernel.org/patch/10282237/ Th

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On 2018-03-04 23:28, Rafael J. Wysocki wrote: use the expected idle period duration returned by cpuidle_select() to tell tick_nohz_idle_go_idle() whether or not to stop the tick. I assume that at the point of going idle, the actual next scheduling tick may happen anywhere between now and 1/HZ.

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On 2018-03-04 23:28, Rafael J. Wysocki wrote: use the expected idle period duration returned by cpuidle_select() to tell tick_nohz_idle_go_idle() whether or not to stop the tick. I assume that at the point of going idle, the actual next scheduling tick may happen anywhere between now and 1/HZ.

Re: [PATCH] cpuidle: Add "cpuidle.use_deepest" to bypass governor and allow HW to go deep

On 2017-11-09 08:38, Len Brown wrote: From: Len Brown While there are several mechanisms (cmdline, sysfs, PM_QOS) to limit cpuidle to shallow idle states, there is no simple mechanism to give the hardware permission to enter the deeptest state permitted by PM_QOS. Here we

Re: [PATCH] cpuidle: Add "cpuidle.use_deepest" to bypass governor and allow HW to go deep

On 2017-11-09 08:38, Len Brown wrote: From: Len Brown While there are several mechanisms (cmdline, sysfs, PM_QOS) to limit cpuidle to shallow idle states, there is no simple mechanism to give the hardware permission to enter the deeptest state permitted by PM_QOS. Here we create the

[tip:perf/core] perf tools: Default to python version 2

Commit-ID: d6a947fb6cdff3a19db93895c746f70b5903a965 Gitweb: http://git.kernel.org/tip/d6a947fb6cdff3a19db93895c746f70b5903a965 Author: Thomas Ilsche AuthorDate: Mon, 4 Aug 2014 15:03:15 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 12 Aug 2014 12:03:08 -0300 perf tools

[tip:perf/core] perf tools: Default to python version 2

Commit-ID: d6a947fb6cdff3a19db93895c746f70b5903a965 Gitweb: http://git.kernel.org/tip/d6a947fb6cdff3a19db93895c746f70b5903a965 Author: Thomas Ilsche thomas.ils...@tu-dresden.de AuthorDate: Mon, 4 Aug 2014 15:03:15 +0200 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Tue

[PATCH v3 2/2] perf tools: Default to python version 2

.x, python2-config N/A Based on / replaces the patch 2/2 by Namhyung Kim. Signed-off-by: Thomas Ilsche --- diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 9ee2008..0528cd37 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -104,10 +104,16 @@ ifdef PARS

[PATCH v3 2/2] perf tools: Default to python version 2

-off-by: Thomas Ilsche thomas.ils...@tu-dresden.de --- diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 9ee2008..0528cd37 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -104,10 +104,16 @@ ifdef PARSER_DEBUG endif ifndef NO_LIBPYTHON - override

Re: [PATCH v2 2/2] perf tools: Default to python version 2

stalling perl-ExtUtils-Embed > config/Makefile:512: No python-config tool was found > config/Makefile:512: Python support will not be built > >> [1] https://www.python.org/dev/peps/pep-0394 >> >> Suggested-by: Thomas Ilsche >> Tested-by: Thomas Ilsche >> Sig

Re: [PATCH v2 2/2] perf tools: Default to python version 2

/peps/pep-0394 Suggested-by: Thomas Ilsche thomas.ils...@tu-dresden.de Tested-by: Thomas Ilsche thomas.ils...@tu-dresden.de Signed-off-by: Namhyung Kim namhy...@kernel.org --- tools/perf/config/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/config

Re: [PATCH 2/2] perf tools: Default to python version 2

was my fault on setting symlink to a > non-existing file for testing. It now works well for me too. > > Can I add your Tested-by then? Yes Tested-by: Thomas Ilsche Plase note that your patch requires the previous patch that just set the default to python2. I tested in an Arch Linux VM wi

Re: [PATCH 2/2] perf tools: Default to python version 2

. It now works well for me too. Can I add your Tested-by then? Yes Tested-by: Thomas Ilsche thomas.ils...@tu-dresden.de Plase note that your patch requires the previous patch that just set the default to python2. I tested in an Arch Linux VM with: A) no system install of python, source

Re: [PATCH 2/2] perf tools: Default to python version 2

Hi Namhyung, apologies for mixing up your first name earlier. On 2014-07-25 12:24, Namhyung Kim wrote: > Hi Thomas, > > On Fri, 25 Jul 2014 11:28:55 +0200, Thomas Ilsche wrote: >> Hi Kim, >> >> On 2014-07-25 05:14, Namhyung Kim wrote: >>> According to P

Re: [PATCH 2/2] perf tools: Default to python version 2

2.7.3 (April 2012), but it is still not available in 2.6.9 (Oct. 2013). So it might be better to use python2 as default but fall back to python if python2 is not available. Best, Thomas Signed-off-by: Thomas Ilsche --- diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index f

Re: [PATCH 1/2] perf tools: Fix make PYTHON override

uess it's a bug slipped into during > the feature checking change. > > Actually, we don't need to check python-config in the feature-checks. > We can just pass appropriate FEATURE_CHECK_*FLAGS. The patch works fine for me. Thanks, Thomas > > Reported-by: Thomas Ilsc

Re: [PATCH 1/2] perf tools: Fix make PYTHON override

into during the feature checking change. Actually, we don't need to check python-config in the feature-checks. We can just pass appropriate FEATURE_CHECK_*FLAGS. The patch works fine for me. Thanks, Thomas Reported-by: Thomas Ilsche thomas.ils...@tu-dresden.de Signed-off-by: Namhyung

Re: [PATCH 2/2] perf tools: Default to python version 2

(April 2012), but it is still not available in 2.6.9 (Oct. 2013). So it might be better to use python2 as default but fall back to python if python2 is not available. Best, Thomas Signed-off-by: Thomas Ilsche thomas.ils...@tu-dresden.de --- diff --git a/tools/perf/config/Makefile b/tools/perf/config

Re: [PATCH 2/2] perf tools: Default to python version 2

Hi Namhyung, apologies for mixing up your first name earlier. On 2014-07-25 12:24, Namhyung Kim wrote: Hi Thomas, On Fri, 25 Jul 2014 11:28:55 +0200, Thomas Ilsche wrote: Hi Kim, On 2014-07-25 05:14, Namhyung Kim wrote: According to PEP 394 recommendation [1], it's more portable to use

Perf: cannot overide PYTHON(_CONFIG)

EATURE_CHECK_[CFLAGS|LDFLAGS]-libpython(-version) needs to be set (before the feature checks are executed) and that the reconstruction of FLAGS_PYTHON_EMBED based on hardcoded python-config needs to be removed. Best Regards, Thomas -- Dipl. Inf. Thomas Ilsche Computer Scientist Highly Adaptive Energy-Eff

Perf: cannot overide PYTHON(_CONFIG)

]-libpython(-version) needs to be set (before the feature checks are executed) and that the reconstruction of FLAGS_PYTHON_EMBED based on hardcoded python-config needs to be removed. Best Regards, Thomas -- Dipl. Inf. Thomas Ilsche Computer Scientist Highly Adaptive Energy-Efficient Computing CRC 912

Re: [PATCH] Provide additional sample information to Python scripts

event was recorded. >> Additionally, provide the call-stack recorded at each event with >> resolved symbols. At the moment, the pointer to the sample struct >> is passed to scripts, which seems to be of little use. The patch >> puts this information in dictionaries for easy

Re: [PATCH] Provide additional sample information to Python scripts

for easy access by Python scripts. Signed-off-by: Joseph Schuchart joseph.schuch...@tu-dresden.de Acked-by: Thomas Ilsche thomas.ils...@tu-dresden.de @@ -359,7 +359,7 @@ static void python_process_general_event struct thread *thread