Internal (Wrapping) Key is a new entity of Intel Key Locker feature. This
internal key is loaded in a software-inaccessible CPU state and used to
encode a data encryption key.
The kernel makes random data and loads it as the internal key in each CPU.
The data need to be invalidated as soon as the
changes v2:
- add back settle_delay_usecs support
- execute power down on the end of the main transfer.
- make it work with 2.5MHz SPI clock
This series is optimizing SPI transfer related CPU load.
Oleksij Rempel (2):
Input: ads7846: convert to full duplex
Input: ads7846: convert to one
This series is optimizing SPI transfer related CPU load.
Oleksij Rempel (2):
Input: ads7846: convert to full duplex
Input: ads7846: convert to one message
drivers/input/touchscreen/ads7846.c | 395 +++-
1 file changed, 151 insertions(+), 244 deletions(-)
--
2.28.0
On Mon, 19 Oct 2020 01:05:57 +0800
Hui Su wrote:
> format the example code.
>
> Signed-off-by: Hui Su
> ---
> Documentation/admin-guide/cpu-load.rst | 63 ++
> 1 file changed, 33 insertions(+), 30 deletions(-)
Hmm...this document wasn't always that way; it looks like m
format the example code.
Signed-off-by: Hui Su
---
Documentation/admin-guide/cpu-load.rst | 63 ++
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/Documentation/admin-guide/cpu-load.rst
b/Documentation/admin-guide/cpu-load.rst
index ebdecf864080..f3ada90e
Documentation generation warns:
Documentation/translations/zh_CN/admin-guide/cpu-load.rst:1:
WARNING: Title overline too short.
Extend title heading markup by one. It was just off by one.
Fixes: e210c66d567c ("doc/zh_CN: add cpu-load Chinese version")
Signed-off-by: Lukas Bulwahn
When start streaming the CPU load could remain very low because almost
all the capture pipeline is done in hardware (i.e. without using the CPU)
and let believe to cpufreq governor that it could use lower frequencies.
If the governor decides to use a too low frequency that becomes a problem
when
On Thu, May 02, 2019 at 11:32:38AM -0700, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98[000] ..
On 02-05-19, 11:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98[000] 290.972410: thermal_powe
On 02/05/2019 20:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98[000] ..
On 02-05-19, 11:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98[000] 290.972410: thermal_powe
The CPU load values passed to the thermal_power_cpu_get_power
tracepoint are zero for all CPUs, unless, unless the
thermal_power_cpu_limit tracepoint is enabled too:
irq/41-rockchip-98[000] 290.972410: thermal_power_cpu_get_power:
cpus=000f freq=180 load={{0x0,0x0,0x0,0x0
From: Josef Bacik
We have no idea how long ago the process went to sleep. It could have just gone
to sleep, in which case we would essentially be counting the load of the process
twice in the previous effective load. Since the history presumably already
exists in the previous cpu load don&#
d.txt
+++ b/Documentation/cpu-load.txt
@@ -1,9 +1,10 @@
+====
CPU load
-
+
-Linux exports various bits of information via `/proc/stat' and
-`/proc/uptime' that userland tools, such as top(1), use to calculate
-the average time system spent in a particular state, for
d.txt
+++ b/Documentation/cpu-load.txt
@@ -1,9 +1,10 @@
+====
CPU load
-
+
-Linux exports various bits of information via `/proc/stat' and
-`/proc/uptime' that userland tools, such as top(1), use to calculate
-the average time system spent in a particular state, for
On Monday, November 14, 2016 10:31:11 AM Srinivas Pandruvada wrote:
> Use get_target_pstate_use_cpu_load() to calculate target P-State for
> devices, which uses preferred power management profile as PM_MOBILE
> in ACPI FADT.
> This may help in resolving some thermal issues caused by low sustained
>
Use get_target_pstate_use_cpu_load() to calculate target P-State for
devices, which uses preferred power management profile as PM_MOBILE
in ACPI FADT.
This may help in resolving some thermal issues caused by low sustained
cpu bound workloads. The current algorithm tend to over provision in this
cas
Use get_target_pstate_use_cpu_load() to calculate target P-State for
devices, which uses preferred power management profile as PM_MOBILE
in ACPI FADT.
This may help in resolving some thermal issues caused by low sustained
cpu bound workloads. The current algorithm tend to over provision in this
cas
before updating nohz CPU load
If we're accessing rq_clock() (e.g. in sched_avg_update()) we should
update the rq clock before calling cpu_load_update(), otherwise any
time calculations will be stale.
All other paths currently call update_rq_clock().
Signed-off-by: Matt Fleming
Signed-o
2016-05-04 3:46 GMT+08:00 Matt Fleming :
> If we're accessing rq_clock() (e.g. in sched_avg_update()) we should
> update the rq clock before calling cpu_load_update(), otherwise any
> time calculations will be stale.
>
> All other paths currently call update_rq_clock().
>
> Cc: Peter Zijlstra
> Cc
If we're accessing rq_clock() (e.g. in sched_avg_update()) we should
update the rq clock before calling cpu_load_update(), otherwise any
time calculations will be stale.
All other paths currently call update_rq_clock().
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Mike Galbraith
Cc: Mel Gorman
Cc:
: Optimize !CONFIG_NO_HZ_COMMON CPU load updates
Some code in CPU load update only concern NO_HZ configs but it is
built on all configurations. When NO_HZ isn't built, that code is harmless
but just happens to take some useless ressources in CPU and memory:
1) one useless field in struct rq
2) ji
: Correctly handle nohz ticks CPU load accounting
Ticks can happen while the CPU is in dynticks-idle or dynticks-singletask
mode. In fact "nohz" or "dynticks" only mean that we exit the periodic
mode and we try to minimize the ticks as much as possible. The nohz
subsystem uses a confus
CPU load functions under a more conventional namespace
The CPU load update related functions have a weak naming convention
currently, starting with update_cpu_load_*() which isn't ideal as
"update" is a very generic concept.
Since two of these functions are public already (and a t
ed. In the best case the
> tick can indeed be actually stopped but there is no guarantee about that.
> If a timer needs to fire one second later, a tick will fire while the
> CPU is in nohz mode and this is a very common scenario.
>
> Now this confusion happens to be a problem with c
Some code in cpu load update only concern NO_HZ configs but it is
built on all configurations. When NO_HZ isn't built, that code is harmless
but just happens to take some useless ressources in CPU and memory:
1) one useless field in struct rq
2) jiffies record on every tick that is never
On Tue, Apr 19, 2016 at 09:01:00AM +0900, Byungchul Park wrote:
> On Mon, Apr 18, 2016 at 03:35:06PM +0200, Frederic Weisbecker wrote:
> > On Mon, Apr 18, 2016 at 06:17:21PM +0900, Byungchul Park wrote:
> > > On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> > > > @@ -4645,11 +
On Mon, Apr 18, 2016 at 03:35:06PM +0200, Frederic Weisbecker wrote:
> On Mon, Apr 18, 2016 at 06:17:21PM +0900, Byungchul Park wrote:
> > On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> > > @@ -4645,11 +4674,11 @@ void cpu_load_update_nohz(int active)
> > > void cpu_load_up
On Wed, Apr 13, 2016 at 03:56:52PM +0200, Frederic Weisbecker wrote:
> Some code in cpu load update only concern NO_HZ configs but it is
> built on all configurations. When NO_HZ isn't built, that code is harmless
> but just happens to take some useless ressources in CPU and memor
On Mon, Apr 18, 2016 at 06:17:21PM +0900, Byungchul Park wrote:
> On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> > @@ -4645,11 +4674,11 @@ void cpu_load_update_nohz(int active)
> > void cpu_load_update_active(struct rq *this_rq)
> > {
> > unsigned long load = weighted_
On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> @@ -4645,11 +4674,11 @@ void cpu_load_update_nohz(int active)
> void cpu_load_update_active(struct rq *this_rq)
> {
> unsigned long load = weighted_cpuload(cpu_of(this_rq));
> - /*
> - * See the mess around cpu_
e_nohz(this_rq, READ_ONCE(jiffies), 0);
> }
>
> /*
> - * Called from tick_nohz_idle_exit() -- try and fix up the ticks we missed.
> + * Record CPU load on nohz entry so we know the tickless load to account
> + * on nohz exit. cpu_load[0] happens then to be updated more frequently
>
hat.
If a timer needs to fire one second later, a tick will fire while the
CPU is in nohz mode and this is a very common scenario.
Now this confusion happens to be a problem with cpu load updates:
cpu_load_update_active() doesn't handle nohz ticks correctly because it
assumes that ticks are co
Some code in cpu load update only concern NO_HZ configs but it is
built on all configurations. When NO_HZ isn't built, that code is harmless
but just happens to take some useless ressources in CPU and memory:
1) one useless field in struct rq
2) jiffies record on every tick that is never
variable.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
sched/nohz-v3
HEAD: 101db6e825806a08e14c3e06b5242c10608db2df
Thanks,
Frederic
---
Frederic Weisbecker (3):
sched: Gather cpu load functions under a more conventional namespace
sched
The cpu load update related functions have a weak naming convention
currently, starting with update_cpu_load_*() which isn't ideal as
"update" is a very generic concept.
Since two of these functions are public already (and a third is to come)
that's enough to introduce a more
On Mon, Apr 11, 2016 at 08:21:31PM +0200, Frederic Weisbecker wrote:
> On Mon, Apr 11, 2016 at 10:53:01AM -0400, Chris Metcalf wrote:
> > On 4/11/2016 9:18 AM, Frederic Weisbecker wrote:
> > >So I tried and it warns about the unused variable tickless_load, so I
> > >would need two scattered ifdeffe
On Mon, Apr 11, 2016 at 10:53:01AM -0400, Chris Metcalf wrote:
> On 4/11/2016 9:18 AM, Frederic Weisbecker wrote:
> >So I tried and it warns about the unused variable tickless_load, so I
> >would need two scattered ifdeffery in the function:
> >
> >@@ -4528,7 +4529,9 @@ decay_load_missed(unsigned l
On 4/11/2016 9:18 AM, Frederic Weisbecker wrote:
So I tried and it warns about the unused variable tickless_load, so I
would need two scattered ifdeffery in the function:
@@ -4528,7 +4529,9 @@ decay_load_missed(unsigned long load, unsigned long
missed_updates, int idx)
static void cpu_load_up
On Fri, Apr 08, 2016 at 07:44:14PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 02:55:22PM +0200, Frederic Weisbecker wrote:
> > > > @@ -4540,17 +4568,8 @@ static void cpu_load_update(struct rq *this_rq,
> > > > unsigned long this_load,
> > > >
> > > > /* scale is effec
On Fri, Apr 08, 2016 at 02:55:22PM +0200, Frederic Weisbecker wrote:
> > > @@ -4540,17 +4568,8 @@ static void cpu_load_update(struct rq *this_rq,
> > > unsigned long this_load,
> > >
> > > /* scale is effectively 1 << i now, and >> i divides by scale */
> > >
> > > - old_load
On Fri, Apr 08, 2016 at 02:53:21PM +0200, Frederic Weisbecker wrote:
> On Fri, Apr 08, 2016 at 11:41:54AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 08, 2016 at 03:07:12AM +0200, Frederic Weisbecker wrote:
> > > +void cpu_load_update_nohz_start(void)
> > > {
> > > struct rq *this_rq = this_rq(
On Fri, Apr 08, 2016 at 12:48:21PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 03:07:13AM +0200, Frederic Weisbecker wrote:
> > index 4c522a7..59a2821 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -7327,8 +7327,9 @@ void __init sched_init(void)
> >
> >
On Fri, Apr 08, 2016 at 11:41:54AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 03:07:12AM +0200, Frederic Weisbecker wrote:
> > +void cpu_load_update_nohz_start(void)
> > {
> > struct rq *this_rq = this_rq();
> > +
> > + /*
> > +* This is all lockless but should be fine. If we
On Fri, Apr 08, 2016 at 03:07:13AM +0200, Frederic Weisbecker wrote:
> index 4c522a7..59a2821 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7327,8 +7327,9 @@ void __init sched_init(void)
>
> for (j = 0; j < CPU_LOAD_IDX_MAX; j++)
> rq->cp
On Fri, Apr 08, 2016 at 03:07:12AM +0200, Frederic Weisbecker wrote:
> +void cpu_load_update_nohz_start(void)
> {
> struct rq *this_rq = this_rq();
> +
> + /*
> + * This is all lockless but should be fine. If weighted_cpuload changes
> + * concurrently we'll exit nohz. And cpu_
The cpu load update related functions have a weak naming convention
currently, starting with update_cpu_load_*() which isn't ideal as
"update" is a very generic concept.
Since two of these functions are public already (and a third is to come)
that's enough to introduce a more
Some code in cpu load update only concern NO_HZ configs but it is
built on all configurations. When NO_HZ isn't built, that code is harmless
but just happens to take some useless ressources in CPU and memory:
1) one useless field in struct rq
2) jiffies record on every tick that is never
hat.
If a timer needs to fire one second later, a tick will fire while the
CPU is in nohz mode and this is a very common scenario.
Now this confusion happens to be a problem with cpu load updates:
cpu_load_update_active() doesn't handle nohz ticks correctly because it
assumes that ticks are co
This series tries to fix issues against CFS cpu load accounting in
nohz configs (both idle and full nohz). Some optimizations coming along.
Following Peterz reviews, I've tried to improve the changelogs. Comments
have been updated as well and some changes have been refactored.
On Sat, Apr 02, 2016 at 09:23:37AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 03:23:06PM +0200, Frederic Weisbecker wrote:
> > Don't bother with the whole pending tickless cpu load machinery if
> > we run a tick periodic kernel. That's less job for the CPU
On Sat, Apr 02, 2016 at 09:15:20AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 03:23:05PM +0200, Frederic Weisbecker wrote:
> > Ticks can happen in the middle of a nohz frame and
>
> I'm still miffed with that.. And this changelog doesn't even explain why
> and how.
Indeed, it looks li
On Sat, Apr 02, 2016 at 09:09:08AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 03:23:04PM +0200, Frederic Weisbecker wrote:
> > This way they are easily grep'able and recognized.
>
> Please mention the actual renames done and the new naming scheme.
Right, I'll add more details.
Thanks
On Fri, Apr 01, 2016 at 03:23:07PM +0200, Frederic Weisbecker wrote:
> To complete the tick periodic kernel optimizations.
-ENOCHANGELOG
On Fri, Apr 01, 2016 at 03:23:06PM +0200, Frederic Weisbecker wrote:
> Don't bother with the whole pending tickless cpu load machinery if
> we run a tick periodic kernel. That's less job for the CPU on ticks.
Again, the changelog really could use help. Is this a pure optimization
On Fri, Apr 01, 2016 at 03:23:05PM +0200, Frederic Weisbecker wrote:
> Ticks can happen in the middle of a nohz frame and
I'm still miffed with that.. And this changelog doesn't even explain why
and how.
> cpu_load_update_active() doesn't handle these correctly. It forgets the
> whole previous ti
On Fri, Apr 01, 2016 at 03:23:04PM +0200, Frederic Weisbecker wrote:
> This way they are easily grep'able and recognized.
Please mention the actual renames done and the new naming scheme.
_idle(struct rq *this_rq)
if (weighted_cpuload(cpu_of(this_rq)))
return;
- __cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0, 0);
+ cpu_load_update(this_rq, READ_ONCE(jiffies), 0);
}
/*
- * Called from tick_nohz_idle_exit() -- try and fix up the ticks we
Don't bother with the whole pending tickless cpu load machinery if
we run a tick periodic kernel. That's less job for the CPU on ticks.
Cc: Byungchul Park
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Pete
Here is another attempt to fix the nohz cpu load accounting after the
first try (https://lwn.net/Articles/671749/), this time using an
entirely different direction, probably more "natural".
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
sched/
To complete the tick periodic kernel optimizations.
Cc: Byungchul Park
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
kern
This way they are easily grep'able and recognized.
Cc: Byungchul Park
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
Documentation/trace/ft
: Consolidate nohz CPU load update code
Lets factorize a bit of code there. We'll even have a third user soon.
While at it, standardize the idle update function name against the
others.
Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Byungchul Park
Cc: Chris Me
On Thu, Feb 18, 2016 at 6:44 AM, Viresh Kumar wrote:
> On 18-02-16, 02:26, Rafael J. Wysocki wrote:
>> Index: linux-pm/drivers/cpufreq/cpufreq_ondemand.c
>> ===
>> --- linux-pm.orig/drivers/cpufreq/cpufreq_ondemand.c
>> +++ linux-pm/d
On 18-02-16, 02:26, Rafael J. Wysocki wrote:
> Index: linux-pm/drivers/cpufreq/cpufreq_ondemand.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_ondemand.c
> +++ linux-pm/drivers/cpufreq/cpufreq_ondemand.c
> @@ -29,6 +29,7 @@
>
>
From: Rafael J. Wysocki
The ->store() callbacks of some tunable sysfs attributes of the
ondemand and conservative governors trigger immediate updates of
the CPU load information for all CPUs "governed" by the given
dbs_data by walking the cpu_dbs_info structures for all online
CPUs
On Mon, Feb 01, 2016 at 11:34:33AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 01, 2016 at 07:05:13PM +0900, Byungchul Park wrote:
> > On Fri, Jan 29, 2016 at 10:50:16AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> > > > So lets check all
On Mon, Feb 01, 2016 at 11:34:33AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 01, 2016 at 07:05:13PM +0900, Byungchul Park wrote:
> > On Fri, Jan 29, 2016 at 10:50:16AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> > > > So lets check all
On Mon, Feb 01, 2016 at 07:05:13PM +0900, Byungchul Park wrote:
> On Fri, Jan 29, 2016 at 10:50:16AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> > > So lets check all the things we call on scheduler_tick():
> > >
> > > _ sched_clock_tick(
On Fri, Jan 29, 2016 at 10:50:16AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> > So lets check all the things we call on scheduler_tick():
> >
> > _ sched_clock_tick(): maybe it doesn't need to be called when idle. I'm not
> > sure.
> >
On Wed, Jan 20, 2016 at 07:26:14PM +0900, Byungchul Park wrote:
> On Wed, Jan 20, 2016 at 02:43:35PM +0900, Byungchul Park wrote:
> >
> > It looks very tricky. I have a question. Do we have to call the
> > scheduler_tick() even while the tick is stopped? IMHO, it seems to be
> > ok even if we won'
On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> So lets check all the things we call on scheduler_tick():
>
> _ sched_clock_tick(): maybe it doesn't need to be called when idle. I'm not
> sure.
> Some code in idle (timers, irqs, ...) might need to call sched_clock().
Onl
On Wed, Jan 20, 2016 at 07:26:14PM +0900, Byungchul Park wrote:
> On Wed, Jan 20, 2016 at 02:43:35PM +0900, Byungchul Park wrote:
> >
> > It looks very tricky. I have a question. Do we have to call the
> > scheduler_tick() even while the tick is stopped? IMHO, it seems to be
> > ok even if we won'
have to focus that. Then we don't need something
accounting a cpu load remotely and periodically, because the local tick
handler can account it well locally.
If it is not true, that is, the timer interrupt for handling rcu callback
or irq work during tick-stopped, is not a tick but just a in
On Wed, Jan 20, 2016 at 07:25:03PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 06:21:07PM +0100, Frederic Weisbecker wrote:
>
> > You mean a periodic call to the above from the housekeepers?
> >
> > I didn't think about doing that because you nacked that approach with
> > scheduler_tic
On Wed, Jan 20, 2016 at 06:21:07PM +0100, Frederic Weisbecker wrote:
> You mean a periodic call to the above from the housekeepers?
>
> I didn't think about doing that because you nacked that approach with
> scheduler_tick(). This isn't much different.
This does _one_ thing, namely load accounti
On Wed, Jan 20, 2016 at 09:42:16AM +0100, Thomas Gleixner wrote:
> On Tue, 19 Jan 2016, Peter Zijlstra wrote:
>
> > On Wed, Jan 13, 2016 at 05:01:28PM +0100, Frederic Weisbecker wrote:
> > > The cpu load update on tick doesn't care about dynticks and as such is
> &g
On Wed, Jan 20, 2016 at 05:56:57PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 03:54:19PM +0100, Frederic Weisbecker wrote:
>
> > > You can simply do:
> > >
> > > for_each_nohzfull_cpu(cpu) {
> > > struct rq *rq = rq_of(cpu);
> > >
> > > raw_spin_
On Wed, Jan 20, 2016 at 03:54:19PM +0100, Frederic Weisbecker wrote:
> > You can simply do:
> >
> > for_each_nohzfull_cpu(cpu) {
> > struct rq *rq = rq_of(cpu);
> >
> > raw_spin_lock(&rq->lock);
> > update_cpu_load_active(rq);
> > raw_spin_unlo
On Wed, Jan 20, 2016 at 09:19:36AM -0600, Christoph Lameter wrote:
> On Wed, 20 Jan 2016, Thomas Gleixner wrote:
>
> > > If the user makes use of full dynticks for soft isolation (for
> > > performance,
> > > can live with a few interrupts...), there can be short moments of
> > > multitasking.
>
On Wed, Jan 20, 2016 at 10:42:56AM -0600, Christoph Lameter wrote:
> On Wed, 20 Jan 2016, Frederic Weisbecker wrote:
>
> > > So we agreed long time ago, that we first fix the issues with s single
> > > task
> > > running undisturbed in user space, i.e. tickless. Those issues have never
> > > bee
On Wed, Jan 20, 2016 at 04:11:14PM +0100, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Frederic Weisbecker wrote:
> > On Wed, Jan 20, 2016 at 10:09:06AM +0100, Peter Zijlstra wrote:
> > > Also, since when can we have enqueues/dequeues while NOHZ_FULL ? I
> > > thought that was the 1 task 100% cpu
On Wed, 20 Jan 2016, Frederic Weisbecker wrote:
> > So we agreed long time ago, that we first fix the issues with s single task
> > running undisturbed in user space, i.e. tickless. Those issues have never
> > been
> > resolved fully, but now you try to add more complexity of extra runnable
> > t
dealing with issues which are
> caused by the lack of continous (remote) accounting.
Well remote accounting of cpu load is something we really need, that's what I
planed to do, but I couldn't find a way to do it correctly without listening on
enqueue/dequeue event first. I said in th
On Wed, 20 Jan 2016, Thomas Gleixner wrote:
> > If the user makes use of full dynticks for soft isolation (for performance,
> > can live with a few interrupts...), there can be short moments of
> > multitasking.
"Soft" isolation? Like soft realtime ... Argh... Please stay away from
corrupting the
On Wed, 20 Jan 2016, Frederic Weisbecker wrote:
> On Wed, Jan 20, 2016 at 10:09:06AM +0100, Peter Zijlstra wrote:
> > Also, since when can we have enqueues/dequeues while NOHZ_FULL ? I
> > thought that was the 1 task 100% cpu case, there are no
> > enqueues/dequeues there.
>
> That's the most opti
handle active tickless
> >
> > change from v1 to v2
> > - add some additional commit message (logic is same exactly)
> >
> > additionally i tried to use the return value of hrtimer_forward() instead of
> > jiffies to get pending tick for updating cpu load. it&#x
nally i tried to use the return value of hrtimer_forward() instead of
> jiffies to get pending tick for updating cpu load. it's easy for
> update_cpu_load_nohz() to do that. but for update_idle_cpu_load(), i need
> more time to think about how to implement it nicely.
Actually because of upd
make __update_cpu_load() handle active tickless
change from v1 to v2
- add some additional commit message (logic is same exactly)
additionally i tried to use the return value of hrtimer_forward() instead of
jiffies to get pending tick for updating cpu load. it's easy for
update_cpu_load_nohz()
NOHZ later with another patch.
i decided to send this patch at first because "cpu load update" is a standalone
problem which is not coupled with other stuffs.
Byungchul Park (2):
sched: make __update_cpu_load() handle active tickless case
sched: consider missed ticks in full NOHZ
inc
On Tue, Oct 13, 2015 at 04:51:05PM +0200, Frederic Weisbecker wrote:
> > And tick_nohz_handler() actually computes the number of ticks -- which
> > we then happily ignore.
> >
> > Why compute it again a few functions down?
>
> Ah, you mean we could get the return value of hrtimer_foward()? Both
>
On Tue, Oct 13, 2015 at 05:37:18PM +0900, Byungchul Park wrote:
> > > find out the pending updates from update_process_times() itself and pass
> > > it to scheduler_tick() which is the one interested in it.
> >
> > tick_nohz_handler() calls tick_sched_handler() ?!
> >
> > And tick_nohz_handler()
On Tue, Oct 13, 2015 at 09:04:36AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 07:45:35PM +0200, Frederic Weisbecker wrote:
> > > I think it will take more than a single patch to rework all of
> > > update_process_times(). And we should also ask Thomas for his opinion,
> > > but I think
On Tue, Oct 13, 2015 at 09:04:36AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 07:45:35PM +0200, Frederic Weisbecker wrote:
> > > I think it will take more than a single patch to rework all of
> > > update_process_times(). And we should also ask Thomas for his opinion,
> > > but I think
On Mon, Oct 12, 2015 at 07:45:35PM +0200, Frederic Weisbecker wrote:
> > I think it will take more than a single patch to rework all of
> > update_process_times(). And we should also ask Thomas for his opinion,
> > but I think we want:
> >
> > - make update_process_times() take a nr_ticks argu
broken here too, I'm not sure if
> Frederic is aware of this or not (I'm sure he's got a fairly big list of
> broken for NO_HZ_FULL).
Indeed and cpu load active is part of what needs to be fixed. I hope this
patchset will help.
>
> > 1. update_proces
On Sun, Oct 04, 2015 at 03:58:19PM +0900, Byungchul Park wrote:
> On Fri, Oct 02, 2015 at 05:59:06PM +0200, Peter Zijlstra wrote:
> > On Fri, Oct 02, 2015 at 04:46:14PM +0900, byungchul.p...@lge.com wrote:
> > > From: Byungchul Park
> > >
> > > in hrtimer_interrupt(), the first tick_program_event
On Fri, Oct 02, 2015 at 05:59:06PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 02, 2015 at 04:46:14PM +0900, byungchul.p...@lge.com wrote:
> > From: Byungchul Park
> >
> > in hrtimer_interrupt(), the first tick_program_event() can be failed
> > because the next timer could be already expired due t
On Fri, Oct 02, 2015 at 04:46:14PM +0900, byungchul.p...@lge.com wrote:
> From: Byungchul Park
>
> in hrtimer_interrupt(), the first tick_program_event() can be failed
> because the next timer could be already expired due to,
> (see the comment in hrtimer_interrupt())
>
> - tracing
> - long last
From: Byungchul Park
in hrtimer_interrupt(), the first tick_program_event() can be failed
because the next timer could be already expired due to,
(see the comment in hrtimer_interrupt())
- tracing
- long lasting callbacks
- being scheduled away when running in a VM
in the case that the first ti
1 - 100 of 290 matches
Mail list logo
