ization was last updated before the
> @@ -354,7 +354,6 @@ static void sugov_update_shared(struct update_util_data
> *hook, u64 time,
>
> raw_spin_lock(&sg_policy->update_lock);
>
> - sugov_get_util(sg_cpu);
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
--
#include
Patrick Bellasi
On 22-Dec 12:46, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 11:02:06AM +0000, Patrick Bellasi wrote:
> > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max
On 22-Dec 13:07, Juri Lelli wrote:
> Hi Peter,
>
> On 22/12/17 12:46, Peter Zijlstra wrote:
> > On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> >
.
Still the observation of Juri is valid: do we wanna really disregard
all the CFS blocked load as soon as there are not CFS tasks?
> + }
>
> /*
>* Ideally we would like to set util_dl as min/guaranteed freq and
--
#include
Patrick Bellasi
On 22-Dec 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +0000, Patrick Bellasi wrote:
> > > I was thinking that since dl is a 'global' scheduler the reservation
> > > would be too and thus the freq just needs a single CPU to be observed;
&g
On 22-Dec 13:43, Juri Lelli wrote:
> On 22/12/17 12:38, Patrick Bellasi wrote:
> > On 22-Dec 13:19, Peter Zijlstra wrote:
> > > On Fri, Dec 22, 2017 at 12:07:37PM +0000, Patrick Bellasi wrote:
> > > > > I was thinking that since dl is a 'global' scheduler
t; */
> bool __checkparam_dl(const struct sched_attr *attr)
> {
> + /* special dl tasks don't actually use any parameter */
> + if (attr->sched_flags & SCHED_FLAG_SUGOV)
> + return true;
> +
> /* deadline != 0 */
> if (attr->sched_deadline == 0)
> return false;
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index a1730e39cbc6..280b421a82e8 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -156,13 +156,33 @@ static inline int task_has_dl_policy(struct task_struct
> *p)
> return dl_policy(p->policy);
> }
>
> +/*
> + * !! For sched_setattr_nocheck() (kernel) only !!
> + *
> + * This is actually gross. :(
> + *
> + * It is used to make schedutil kworker(s) higher priority than
> SCHED_DEADLINE
> + * tasks, but still be able to sleep. We need this on platforms that cannot
> + * atomically change clock frequency. Remove once fast switching will be
> + * available on such platforms.
> + *
> + * SUGOV stands for SchedUtil GOVernor.
> + */
> +#define SCHED_FLAG_SUGOV 0x1000
> +
> +static inline int dl_entity_is_special(struct sched_dl_entity *dl_se)
This should better return a bool...
> +{
... and maybe it can optimize some builds via constants propagations to add:
#ifdef CONFIG_CPU_FREQ_GOV_SCHEDUTIL
> + return dl_se->flags & SCHED_FLAG_SUGOV;
#else
return false;
#endif
> +}
> +
> /*
> * Tells if entity @a should preempt entity @b.
> */
> static inline bool
> dl_entity_preempt(struct sched_dl_entity *a, struct sched_dl_entity *b)
> {
> - return dl_time_before(a->deadline, b->deadline);
> + return dl_entity_is_special(a) ||
> +dl_time_before(a->deadline, b->deadline);
Given that being special is less likely, perhaps better to have:
return dl_time_before(a->deadline, b->deadline) ||
dl_entity_is_special(a);
> }
>
> /*
> --
> 2.14.3
>
--
#include
Patrick Bellasi
;t result in the same behavior.
> + * For RT tasks, the schedutil governor shoots the frequency to maximum.
> + * Special care must be taken to ensure that this kthread doesn't result
> + * in the same behavior.
>*
>* This is (mostly) guaranteed by the work_in_progress flag. The flag is
>* updated only at the end of the sugov_work() function and before that
> --
> 2.14.3
>
--
#include
Patrick Bellasi
t sugov_policy *sg_policy = sg_cpu->sg_policy;
> - unsigned long util, max;
> unsigned int next_f;
>
> - sugov_get_util(&util, &max, sg_cpu->cpu);
> -
> raw_spin_lock(&sg_policy->update_lock);
>
> - sg_cpu->util = util;
> - sg_cpu->max = max;
> + sugov_get_util(sg_cpu);
> sg_cpu->flags = flags;
>
> sugov_set_iowait_boost(sg_cpu, time, flags);
> --
> 2.14.3
>
--
#include
Patrick Bellasi
On 05-Dec 16:24, Juri Lelli wrote:
> On 05/12/17 15:09, Patrick Bellasi wrote:
> > > + /*
> > > + * Ideally we would like to set util_dl as min/guaranteed freq and
> > > + * util_cfs + util_dl as requested freq. However, cpufreq is not yet
> > > + * read
e expected utilization of a CPU which,
for example, has just got a big task running after a long sleep period,
and ultimately it allows to select the best frequency to run a task
right after it wakes up.
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Eggemann
Cc: Ingo
cally:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijls
m-summit/Downloads/OSPM_PELT_DecayClampingVsUtilEst.pdf
video: http://youtu.be/adnSHPBGS-w
Changes v1->v2:
- rebase on top of v4.15-rc2
- tested that overhauled PELT code does not affect the util_est
Patrick Bellasi (4):
sched/fair: always used unsigned long for utilization
sched/fair: add util_est on top
always
use the native type.
As well as improving code consistency this is expected also benefits
code paths where utilizations should be clamped by avoiding further type
conversions or ugly type casts.
Signed-off-by: Patrick Bellasi
Reviewed-by: Chris Redpath
Reviewed-by: Brendan Jackman
CPU.
This allows to properly represent the expected utilization of a CPU which,
for example, has just got a big task running since a long sleep
period.
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. W
Hi Vincent,
On 06-Dec 10:39, Vincent Guittot wrote:
> Hi Patrick,
>
> On 30 November 2017 at 12:47, Patrick Bellasi wrote:
[...]
> > static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int
> > flags)
> > @@ -1564,6 +1564,9 @@ pick_next_task_rt(struct
On 13-Dec 17:03, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 05:10:14PM +0000, Patrick Bellasi wrote:
> > With this feature enabled, the measured overhead is in the range of ~1%
> > on the same HW/SW test configuration.
>
> That's quite a lot; did you look where that
On 13-Dec 17:19, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote:
> > @@ -562,6 +577,12 @@ struct task_struct {
> >
> > const struct sched_class*sched_class;
> > struct sched_entity se;
> &g
On 13-Dec 18:03, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 04:36:53PM +0000, Patrick Bellasi wrote:
> > On 13-Dec 17:19, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote:
> > > > @@ -562,6
On 13-Dec 17:16, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote:
> > +static inline void util_est_dequeue(struct task_struct *p, int flags)
> > +{
> > + struct cfs_rq *cfs_rq = &task_rq(p)->cfs;
> > + unsigned long util
On 13-Dec 17:05, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote:
> > + if (cfs_rq->nr_running > 0) {
> > + util_est = cfs_rq->util_est_runnable;
> > + util_est -= task_util_est(p);
&g
On 15-Dec 15:07, Peter Zijlstra wrote:
> On Fri, Dec 15, 2017 at 02:02:18PM +0000, Patrick Bellasi wrote:
> > On 13-Dec 17:05, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote:
> > > > + if (cfs_rq->nr_running > 0
On 15-Dec 13:53, Peter Zijlstra wrote:
> On Fri, Dec 15, 2017 at 12:14:17PM +0000, Patrick Bellasi wrote:
> > On 13-Dec 17:16, Peter Zijlstra wrote:
>
> > > > + /*
> > > > +* Skip update of task's estimated utilization when its EWMA is
>
Hi Mike,
On 13-Dec 18:56, Mike Galbraith wrote:
> On Tue, 2017-12-05 at 17:10 +0000, Patrick Bellasi wrote:
> > This is a respin of:
> >https://lkml.org/lkml/2017/11/9/546
> > which has been rebased on v4.15-rc2 to have util_est now working on top
> > of the recent
Hi Rafael,
On 16-Dec 03:35, Rafael J. Wysocki wrote:
> On Tuesday, December 5, 2017 6:10:18 PM CET Patrick Bellasi wrote:
[...]
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 2f52ec0f1539..465430d99440 100644
&
from:
- void (*func)(struct update_util_data *data, u64 time,
- unsigned int flags))
+ void (*func)(struct update_util_data *data, u64 time,
+ unsigned int flags, bool set))
Where the additional boolean is actually used to define which
operation we wanna perform on the flags?
--
#include
Patrick Bellasi
Hi Viresh,
On 12-Dec 17:07, Viresh Kumar wrote:
> On 07-12-17, 12:45, Patrick Bellasi wrote:
> > On 07-Dec 10:31, Viresh Kumar wrote:
[...]
> I think its important to fix the basic mechanism of util update than fixing
> corner cases with workarounds. I attempted a simpler app
anyway. So, unless I misunderstood
> > its
> > purpose, it was doing anything helpful.
>
> That was actually my understanding as well. Your patch made me notice
> it.
>
> >
> > I need to remove it otherwise the RT flag may remain set for a very long
> > time
> > unnecessarily. That would be until the time the last RT task is not
> > dequeued.
> > Consider this for example: we are at max freq when sugov_start() is called
> > and
> > it sets the RT flag, but there is no RT task to run. Now, we have tons of
> > CFS
> > tasks but we always keep running at max because of the flag. Even the
> > schedutil
> > RT thread doesn't get a chance to run/deququed, because we never want a freq
> > change with the RT flag and stay at max.
> >
> > Makes sense ?
>
> Yes. I guess it's working ok for now because of the problem this patch,
> and Patrick's, address (always overwriting).
Yes, makes sens to me too ;-)
--
#include
Patrick Bellasi
rick
.:: References
[1] https://lkml.org/lkml/2017/2/28/355
[2] slides:
http://retis.sssup.it/ospm-summit/Downloads/OSPM_PELT_DecayClampingVsUtilEst.pdf
video: http://youtu.be/6MC1jbYbQTo
[3] https://lkml.org/lkml/2017/4/11/670
[4] https://lkml.org/lkml/2017/3/20/688
Patrick Bellasi (6):
sched/
maximum different clamp values
supported.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Tejun Heo
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
init/Kconfig | 19 +++
kernel/sched/core.c | 348 ++
t directly affecting the user experience
by running them only up to a maximum "allowed" frequency
The default values for boosting and capping are defined to be:
- util_min: 0
- util_max: SCHED_CAPACITY_SCALE
which means that by default no boosting/capping is enforced.
Signed-off-by:
make the RT class more friendly for power/energy
sensitive use-cases.
This patch extends the usage of util_{min,max} to the RT/DL classes.
Whenever a task in these classes is RUNNABLE, the util required is
defined by the constraints of the CPU control group the task belongs to.
Signed-off-by: Patrick
schedule a less boosted or more clamped task.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Tejun Heo
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
include/linux/sched.h | 5 ++
kernel/sched/core
sks we
use the same locking schema use by __set_cpus_allowed_ptr(). This might
lock the (previous) RQ of a !RUNNABLE task, but that's the price to pay
to safely serialize util_{min,max} updates with RQ's enqueues, dequeues
and migration operations.
Signed-off-by: Patrick Bellasi
Cc: In
ntation:
Documentation/cgroup-v2.txt
This patch provides the basic support to expose the two new attributes and
to validate their run-time update based on the "limits" of the
aforementioned RDM schema.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Tejun Heo
resent the expected utilization of a CPU which,
for example, it has just got a big task running after a long sleep period,
and ultimately it allows to select the best frequency to run a task
right after it wakes up.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Paul Turner
C
mit/Downloads/OSPM_PELT_DecayClampingVsUtilEst.pdf
video: http://youtu.be/adnSHPBGS-w
[2] https://gist.github.com/derkling/6d1d3a3164b0291ef64fa409f61a81cb
[3] https://lkml.org/lkml/2016/10/28/84
[4] https://patchwork.kernel.org/patch/9876769/
(*) Better saying "it should be", si
placement decisions
- top-level CPU's RQs
since we want to better support frequencies selection for a CPU
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Vincent Guittot
Cc: Morten Rasmussen
Cc: Rafael J. Wysocki
Cc: linux-kernel@
represent the expected utilization of a CPU which,
for example it has just got a big task running since a long sleep
period.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Vincent Guittot
Cc: Morten Rasmussen
Cc: Rafael J. Wysocki
Cc: linux-kernel@vger.
On 29-Aug 12:11, Pavan Kondeti wrote:
> On Fri, Aug 25, 2017 at 3:50 PM, Patrick Bellasi
> wrote:
> > The util_avg signal computed by PELT is too variable for some use-cases.
> > For example, a big task waking up after a long sleep period will have its
> > utilization a
On 29-Aug 10:06, Pavan Kondeti wrote:
> Hi Patrick,
>
> On Fri, Aug 25, 2017 at 3:50 PM, Patrick Bellasi
> wrote:
> > The util_avg signal computed by PELT is too variable for some use-cases.
> > For example, a big task waking up after a long sleep period will have it
On 29-Aug 10:15, Pavan Kondeti wrote:
> On Fri, Aug 25, 2017 at 3:50 PM, Patrick Bellasi
> wrote:
> > When the scheduler looks at the CPU utlization, the current PELT value
> > for a CPU is returned straight away. In certain scenarios this can have
> > undesired side e
On 28-Aug 11:23, Tejun Heo wrote:
> Hello,
Hi Teo,
> No idea whether this makes sense overall. I'll just comment on the
> cgroup interface part.
Thanks for the feedback, some comments follow inline...
> On Thu, Aug 24, 2017 at 07:08:52PM +0100, Patrick Bellasi wrote:
>
On 06-Jun 17:56, Rafael J. Wysocki wrote:
> On Tue, Jun 6, 2017 at 11:26 AM, Viresh Kumar wrote:
> > On 02-03-17, 15:45, Patrick Bellasi wrote:
> >> diff --git a/include/linux/sched.h b/include/linux/sched.h
> >> index e2ed46d..739b29d 100644
> >> --- a/incl
@@ struct cpuidle_state;
> #define TASK_ON_RQ_MIGRATING 2
>
> extern __read_mostly int scheduler_running;
> +extern unsigned int capacity_margin __read_mostly;
>
> extern unsigned long calc_load_update;
> extern atomic_long_t calc_load_tasks;
> --
> 2.7.4
>
--
#include
Patrick Bellasi
ces
==
[1] https://lkml.org/lkml/2017/3/2/385
[2] https://gist.github.com/derkling/0cd7210e4fa6f2ec3558073006e5ad70
Patrick Bellasi (6):
cpufreq: schedutil: ignore sugov kthreads
cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
cpufreq: schedutil: ensure max frequency
does not make sense for it to bias
the schedutil's frequency selection policy.
This patch exploits the information related to the current task to silently
ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
the sugov kthread is running.
Signed-off-by: Patrick Bellasi
t should be possible.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Changes from v1:
- added "unlikely()" around the statement (SteveR)
---
include/linux/sc
not in progress, a frequency switch is always authorized when
running in "rt_mode", i.e. the current task in a CPU belongs to the
RT/DL class.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: linux-kernel@vger.kernel.org
citly the schedutils
update calls in the only sensible places, which are:
- when an RT task wakeups and it's enqueued in a CPU
- when we actually pick a RT task for execution
- at each tick time
- when a task is set to be RT
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
its usage to be better in
sync with the current status of a CPU.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
kernel/sched/cpufreq_schedutil.c | 3 +--
1 file
, it makes more sense to have flags
aggregation in the schedutil code instead of the core scheduler.
Signed-off-by: Patrick Bellasi
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Steve Muckle
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Changes
G_DEBUG_PREEMPT
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
Reviewed-by: Alessio Balsini
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Joel Fernandes
Cc: Linux-kernel@vger.kernel.org
---
Fix kernel compilation for this configuration:
!CONFIG_DEBUG_PREEMPT && CONFIG_PREEMP
On 04-Dec 06:26, Steven Rostedt wrote:
> On Mon, 4 Dec 2017 09:46:42 +
> Patrick Bellasi wrote:
>
> > The new preempt enable/disable events introduced by:
> >
> > d59158162 tracing: Add support for preempt and irq enable/disable events
> >
> > ar
Hi Viresh,
On 07-Dec 10:31, Viresh Kumar wrote:
> On 30-11-17, 11:47, Patrick Bellasi wrote:
> > diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> > index d1ad3d825561..bb5f778db023 100644
> > --- a/include/linux/sched/cpufreq.h
> > +++ b/in
On 07-Dec 10:35, Viresh Kumar wrote:
> On 30-11-17, 11:47, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 67339ccb5595..448f49de5335 100644
> > --- a/kernel/sched/cpufreq_schedut
On 07-Dec 10:45, Viresh Kumar wrote:
> On 30-11-17, 15:57, Patrick Bellasi wrote:
> > Yes, that's a pretty trivial update with a confusing changelog.
> >
> > If we think it's worth to keep (and correct as well) I'll update the
> > commit message.
>
On 07-Dec 14:54, Viresh Kumar wrote:
> On 30-11-17, 16:42, Patrick Bellasi wrote:
> > On 30-Nov 17:12, Juri Lelli wrote:
> > > Not sure about this though, not my call :). I guess this still helps
> > > until we get the DL changes in.
> >
> > Yes, agree... w
the
99 percentile.
Signed-off-by: Patrick Bellasi
Signed-off-by: Chris Redpath
Reviewed-by: Dietmar Eggemann
Reviewed-by: Brendan Jackman
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
---
kernel/sched/core.c | 9 ++---
kernel/sched/sched.h | 25 ++--
s, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better both tasks placement decisions as well as
to better support frequencies selection for a CPU
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Egg
e expected utilization of a CPU which,
for example, it has just got a big task running after a long sleep period,
and ultimately it allows to select the best frequency to run a task
right after its wakes up.
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Eggemann
slides:
http://retis.sssup.it/ospm-summit/Downloads/OSPM_PELT_DecayClampingVsUtilEst.pdf
video: http://youtu.be/adnSHPBGS-w
Patrick Bellasi (4):
sched/fair: always used unsigned long for utilization
sched/fair: add util_est on top of PELT
sched/fair: use util_est in LB and WU paths
sched/cpuf
always
use the native type.
As well as improving code consistency this is expected also benefits
code paths where utilizations should be clamped by voiding further type
conversions or ugly type casts.
Signed-off-by: Patrick Bellasi
Reviewed-by: Chris Redpath
Reviewed-by: Brendan Jackman
CPU.
This allows to properly represent the expected utilization of a CPU which,
for example it has just got a big task running since a long sleep
period.
Signed-off-by: Patrick Bellasi
Reviewed-by: Brendan Jackman
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. W
ible.
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Changes from v2:
- use cpufreq_update_util() instead of cpufreq_update_this_cpu()
-
nes.
Cheers Patrick
.:: References
==
[1] https://lkml.org/lkml/2017/7/4/495
[2] https://gist.github.com/derkling/0cd7210e4fa6f2ec3558073006e5ad70
Patrick Bellasi (6):
cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
cpufreq: schedutil: ensure max frequency while running RT/DL t
its usage to be better in
sync with the current status of a CPU.
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Changes from v2:
- rebase
in progress, a frequency switch is always authorized when
running in "rt_mode", i.e. the current task in a CPU belongs to the
RT/DL class.
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: li
does not make sense for it to bias
the schedutil's frequency selection policy.
This patch exploits the information related to the current task to silently
ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
the sugov kthread is running.
Signed-off-by: Patrick Bellasi
citly the schedutils
update calls in the only sensible places, which are:
- when an RT task wakes up and it's enqueued in a CPU
- when we actually pick a RT task for execution
- at each tick time
- when a task is set to be RT
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
C
e sense to have flags
aggregation in the schedutil code instead of the core scheduler.
Signed-off-by: Patrick Bellasi
Reviewed-by: Dietmar Eggemann
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Steve Muckle
Cc: linux-kernel@vger.kernel.org
Cc: linux...@
On 30-Nov 14:12, Juri Lelli wrote:
> Hi,
>
> On 30/11/17 11:47, Patrick Bellasi wrote:
>
> [...]
>
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 2f52ec0f1539..67339ccb5595 100644
> > --- a/kernel/
On 30-Nov 14:17, Juri Lelli wrote:
> Hi,
>
> On 30/11/17 11:47, Patrick Bellasi wrote:
>
> [...]
>
> > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct update_util_data
> > *hook, u64 time,
> > struct sugov_policy *sg_policy = sg_cpu->sg_
On 30-Nov 14:36, Juri Lelli wrote:
> Hi,
>
> On 30/11/17 11:47, Patrick Bellasi wrote:
> > The policy in use for RT/DL tasks sets the maximum frequency when a task
> > in these classes calls for a cpufreq_update_util(). However, the
> > current implementation is
On 30-Nov 14:22, Juri Lelli wrote:
> Hi,
>
> On 30/11/17 11:47, Patrick Bellasi wrote:
> > Currently the utilization of the FAIR class is collected before locking
> > the policy. Although that should not be a big issue for most cases, we
> > also don't really kn
On 30-Nov 14:41, Juri Lelli wrote:
> Hi,
>
> On 30/11/17 11:47, Patrick Bellasi wrote:
> > In system where multiple CPUs shares the same frequency domain a small
> > workload on a CPU can still be subject to frequency spikes, generated by
> > the activation of the sugo
On 30-Nov 17:02, Juri Lelli wrote:
> On 30/11/17 15:41, Patrick Bellasi wrote:
> > On 30-Nov 14:12, Juri Lelli wrote:
> > > Hi,
> > >
> > > On 30/11/17 11:47, Patrick Bellasi wrote:
> > >
> > > [...]
> > >
> > >
On 30-Nov 17:12, Juri Lelli wrote:
> On 30/11/17 16:02, Patrick Bellasi wrote:
> > On 30-Nov 14:41, Juri Lelli wrote:
>
> [...]
>
> > > If the DL changes (which I shall post again as soon as tip/sched/core is
> > > bumped up to 4.15-rc1) get in first, this is
the
99 percentile.
Signed-off-by: Patrick Bellasi
Signed-off-by: Chris Redpath
Reviewed-by: Dietmar Eggemenn
Reviewed-by: Brendan Jackman
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
---
kernel/sched/core.c | 9 ++---
kernel/sched/sched.h | 25 ++--
On 08-Nov 11:03, Ingo Molnar wrote:
>
> * tip-bot for Patrick Bellasi wrote:
>
> > Commit-ID: 692ee9a79c14c9f707eeb03754a26b9427c0e005
> > Gitweb:
> > https://git.kernel.org/tip/692ee9a79c14c9f707eeb03754a26b9427c0e005
> > Author: Patrick Bellasi
>
On 08-Nov 11:02, Patrick Bellasi wrote:
> On 08-Nov 11:03, Ingo Molnar wrote:
> >
> > * tip-bot for Patrick Bellasi wrote:
> >
> > > Commit-ID: 692ee9a79c14c9f707eeb03754a26b9427c0e005
> > > Gitweb:
> > > https://git.kernel.org/tip/692ee
Commit-ID: f01415fdbfe83380c2dfcf90b7b26042f88963aa
Gitweb: https://git.kernel.org/tip/f01415fdbfe83380c2dfcf90b7b26042f88963aa
Author: Patrick Bellasi
AuthorDate: Tue, 5 Dec 2017 17:10:15 +
Committer: Ingo Molnar
CommitDate: Wed, 10 Jan 2018 11:30:28 +0100
sched/fair: Use
Commit-ID: 7f65ea42eb00bc902f1c37a71e984e4f4064cfa9
Gitweb: https://git.kernel.org/tip/7f65ea42eb00bc902f1c37a71e984e4f4064cfa9
Author: Patrick Bellasi
AuthorDate: Fri, 9 Mar 2018 09:52:42 +
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 08:11:06 +0100
sched/fair: Add
Commit-ID: f9be3e5961c5554879a491961187472e923f5ee0
Gitweb: https://git.kernel.org/tip/f9be3e5961c5554879a491961187472e923f5ee0
Author: Patrick Bellasi
AuthorDate: Fri, 9 Mar 2018 09:52:43 +
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 08:11:07 +0100
sched/fair: Use
Commit-ID: a07630b8b2c16f82fd5b71d890079f4dd7599c1d
Gitweb: https://git.kernel.org/tip/a07630b8b2c16f82fd5b71d890079f4dd7599c1d
Author: Patrick Bellasi
AuthorDate: Fri, 9 Mar 2018 09:52:44 +
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 08:11:08 +0100
sched/cpufreq/schedutil
Commit-ID: d519329f72a6f36bc4f2b85452640cfe583b4f81
Gitweb: https://git.kernel.org/tip/d519329f72a6f36bc4f2b85452640cfe583b4f81
Author: Patrick Bellasi
AuthorDate: Fri, 9 Mar 2018 09:52:45 +
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 08:11:09 +0100
sched/fair: Update
Commit-ID: 92a801e5d5b7a893881c1676b15dd246727ccd16
Gitweb: https://git.kernel.org/tip/92a801e5d5b7a893881c1676b15dd246727ccd16
Author: Patrick Bellasi
AuthorDate: Mon, 5 Nov 2018 14:53:59 +
Committer: Ingo Molnar
CommitDate: Mon, 12 Nov 2018 06:17:52 +0100
sched/fair: Mask
Commit-ID: 8ecf04e11283a28ca88b8b8049ac93c3a99fcd2c
Gitweb: https://git.kernel.org/tip/8ecf04e11283a28ca88b8b8049ac93c3a99fcd2c
Author: Patrick Bellasi
AuthorDate: Thu, 24 May 2018 15:10:22 +0100
Committer: Ingo Molnar
CommitDate: Fri, 25 May 2018 08:04:52 +0200
sched/cpufreq: Modify
Commit-ID: 2539fc82aa9b07d968cf9ba1ffeec3e0416ac721
Gitweb: https://git.kernel.org/tip/2539fc82aa9b07d968cf9ba1ffeec3e0416ac721
Author: Patrick Bellasi
AuthorDate: Thu, 24 May 2018 15:10:23 +0100
Committer: Ingo Molnar
CommitDate: Fri, 25 May 2018 08:04:56 +0200
sched/fair: Update
The following commit has been merged into the sched/core branch of tip:
Commit-ID: babbe170e053c6ec2343751749995b7b9fd5fd2c
Gitweb:
https://git.kernel.org/tip/babbe170e053c6ec2343751749995b7b9fd5fd2c
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:10 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 0413d7f33e60751570fd6c179546bde2f7d82dcb
Gitweb:
https://git.kernel.org/tip/0413d7f33e60751570fd6c179546bde2f7d82dcb
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:11 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 2480c093130f64ac3a410504fa8b3db1fc4b87ce
Gitweb:
https://git.kernel.org/tip/2480c093130f64ac3a410504fa8b3db1fc4b87ce
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:06 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 7274a5c1bbec45f06f1fff4b8c8b5855b6cc189d
Gitweb:
https://git.kernel.org/tip/7274a5c1bbec45f06f1fff4b8c8b5855b6cc189d
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:08 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 3eac870a324728e5d1711840dad70bcd37f3
Gitweb:
https://git.kernel.org/tip/3eac870a324728e5d1711840dad70bcd37f3
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:09 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 0b60ba2dd342016e4e717dbaa4ca9af3a43f4434
Gitweb:
https://git.kernel.org/tip/0b60ba2dd342016e4e717dbaa4ca9af3a43f4434
Author:Patrick Bellasi
AuthorDate:Thu, 22 Aug 2019 14:28:07 +01:00
Commit-ID: 69842cba9ace84849bb9b8edcdf2cefccd97901c
Gitweb: https://git.kernel.org/tip/69842cba9ace84849bb9b8edcdf2cefccd97901c
Author: Patrick Bellasi
AuthorDate: Fri, 21 Jun 2019 09:42:02 +0100
Committer: Ingo Molnar
CommitDate: Mon, 24 Jun 2019 19:23:44 +0200
sched/uclamp: Add
Commit-ID: 60daf9c19410604f08c99e146bc378c8a64f4ccd
Gitweb: https://git.kernel.org/tip/60daf9c19410604f08c99e146bc378c8a64f4ccd
Author: Patrick Bellasi
AuthorDate: Fri, 21 Jun 2019 09:42:03 +0100
Committer: Ingo Molnar
CommitDate: Mon, 24 Jun 2019 19:23:44 +0200
sched/uclamp: Add
Commit-ID: e8f14172c6b11e9a86c65532497087f8eb0f91b1
Gitweb: https://git.kernel.org/tip/e8f14172c6b11e9a86c65532497087f8eb0f91b1
Author: Patrick Bellasi
AuthorDate: Fri, 21 Jun 2019 09:42:05 +0100
Committer: Ingo Molnar
CommitDate: Mon, 24 Jun 2019 19:23:45 +0200
sched/uclamp: Add
Commit-ID: e496187da71070687b55ff455e7d8d7d7f0ae0b9
Gitweb: https://git.kernel.org/tip/e496187da71070687b55ff455e7d8d7d7f0ae0b9
Author: Patrick Bellasi
AuthorDate: Fri, 21 Jun 2019 09:42:04 +0100
Committer: Ingo Molnar
CommitDate: Mon, 24 Jun 2019 19:23:45 +0200
sched/uclamp: Enforce
Commit-ID: 1d6362fa0cfc8c7b243fa92924429d826599e691
Gitweb: https://git.kernel.org/tip/1d6362fa0cfc8c7b243fa92924429d826599e691
Author: Patrick Bellasi
AuthorDate: Fri, 21 Jun 2019 09:42:06 +0100
Committer: Ingo Molnar
CommitDate: Mon, 24 Jun 2019 19:23:46 +0200
sched/core: Allow
701 - 800 of 808 matches
Mail list logo
