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
a
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 pick
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 tru
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 from
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
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 tick_nohz_
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
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
git://git.kernel.org/pub/scm/linux/kernel/git/rafael
ange 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 the tick.
HTH
--
Dipl. Inf. Thomas Ilsche
Compute
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
ick is not going to be stopped 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.
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.
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 "cpuidle.u
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
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
les. Disabling perl scripting
> support, consider installing 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
sting. It 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 L
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
ython 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
in
I guess 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-
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
ent 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
22 matches
Mail list logo
