Hi,
On 11/05/17 11:27, Juri Lelli wrote:
> On 11/05/17 10:59, Greg KH wrote:
> > On Thu, May 11, 2017 at 09:48:30AM +0100, Juri Lelli wrote:
> > > Hi Greg,
> > >
> > > I'm not sure what your plans are with this set. Are we targeting 4.12?
> > >
On 25/05/17 15:18, Greg KH wrote:
> On Wed, May 24, 2017 at 03:45:15PM +0100, Juri Lelli wrote:
> > Hi,
> >
> > On 11/05/17 11:27, Juri Lelli wrote:
> > > On 11/05/17 10:59, Greg KH wrote:
> > > > On Thu, May 11, 2017 at 09:48:30AM
Hi,
On 23/05/17 11:00, Byungchul Park wrote:
> When cpudl_find() returns any among free_cpus, the cpu might not be
> closer than others, considering sched domain. For example:
>
>this_cpu: 15
>free_cpus: 0, 1,..., 14 (== later_mask)
>best_cpu: 0
>
>topology:
>
>0 --+
>
Hi,
On 23/05/17 11:00, Byungchul Park wrote:
> Currently cpudl_find() returns the best cpu that means it has the
> maximum dl, however, the value is already kept in later_mask and the
> return value is not referred directly any more.
>
> Now, it's enough to return whether CPUs were found or not,
Hi Joel,
On 09/07/17 10:08, Joel Fernandes wrote:
> Currently the iowait_boost feature in schedutil makes the frequency go to max.
> This feature was added to handle a case that Peter described where the
> throughput of operations involving continuous I/O requests [1] is reduced due
> to running a
On 10/07/17 22:12, Joel Fernandes wrote:
> Hi Juri,
>
> On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli wrote:
> > Hi Joel,
> >
> > On 09/07/17 10:08, Joel Fernandes wrote:
[...]
> >> static void sugov_iowait_boost(struct sugov_cp
On 11/07/17 07:33, Joel Fernandes wrote:
> Hi Juri,
>
> On Tue, Jul 11, 2017 at 12:14 AM, Juri Lelli wrote:
> [..]
> >> > Considering it a per-cpu thing, isn't enough that it gets bumped up or
> >> > decayed only when a CPU does an update (by using
On 11/07/17 18:18, Peter Zijlstra wrote:
> On Wed, Jul 05, 2017 at 09:59:00AM +0100, Juri Lelli wrote:
> > @@ -4065,6 +4067,9 @@ static int __sched_setscheduler(struct task_struct *p,
> > }
> >
> > if (user) {
> > + if (attr-
On 11/07/17 18:17, Peter Zijlstra wrote:
> On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote:
> > delta_ns = time - j_sg_cpu->last_update;
> > if (delta_ns > TICK_NSEC) {
> > j_sg_cpu->iowait_boost = 0;
&g
Worker kthread needs to be able to change frequency for all other
threads.
Make it special, just under STOP class.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
Cc: Claudio Scordino
---
Changes from RFCv0:
- use a high
ed-by: Claudio Scordino
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
---
Changes from RFCv0:
- modify comment regarding periodic RT updates (Claudio)
---
kernel/sched/deadline.c | 7 ---
kernel/sched/sched.h
: Claudio Scordino
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
---
Changes from RFCv0:
- use BW_SHIFT (Peter)
- add comment about guaranteed and requested freq (Peter)
- modify comment about go to max behaviour
d-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
Cc: Claudio Scordino
---
kernel/sched/cpufreq_schedutil.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/k
sd parameter is never used in arch_scale_freq_capacity (and it's hard to
see where information coming from scheduling domains might help doing
frequency invariance scaling).
Remove it; also in anticipation of moving arch_scale_freq_capacity
outside CONFIG_SMP.
Signed-off-by: Juri Lell
invariance.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
---
include/linux/sched/topology.h | 12 ++--
kernel/sched/sched.h | 13 ++---
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/include/linux/sched/topology.h b/include/linux/sched
m scheduling classes
Please have a look. Feedback and comments are, as usual, more than welcome.
In case you would like to test this out:
git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfc-v1
Best,
- Juri
Juri Lelli (8):
sched/cpufreq_schedutil: make use of DEADLINE utilization sig
() parameter list.
After this change, aggregation of the different signals has to be performed
by sugov_get_util() users (so that they can decide what to do with the
different signals).
Suggested-by: Rafael J. Wysocki
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J
specified profiling the task execution at max frequency on
biggest capacity core) gets thus scaled accordingly.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
Cc: Claudio Scordino
---
kernel/sched/deadline.c | 26
Hi Viresh,
On 06/07/17 15:52, Viresh Kumar wrote:
> On 06-07-17, 10:49, Dietmar Eggemann wrote:
[...]
> > static void parsing_done_workfn(struct work_struct *work)
> > {
> > + free_cpumask_var(cpus_to_visit);
> > cpufreq_unregister_notifier(&init_cpu_capacity_notifier,
> >
On 06/07/17 11:57, Steven Rostedt wrote:
> On Wed, 5 Jul 2017 09:58:57 +0100
> Juri Lelli wrote:
>
> > Hi,
> >
> > v1 of the RFC set implementing frequency/cpu invariance and OPP selection
> > for
>
> It would be nice if you specify what "OPP"
On 06/07/17 21:43, Joel Fernandes wrote:
> On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi
> wrote:
[...]
> > @@ -304,6 +304,12 @@ static void sugov_update_shared(struct
> > update_util_data *hook, u64 time,
> >
> > sg_cpu->util = util;
> > sg_cpu->max = max;
> > +
> > +
Hi,
On 06/07/17 20:56, Joel Fernandes wrote:
> Hi Juri,
>
> On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote:
[...]
> > if (attr->sched_flags &
> > - ~(SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_RECLAIM))
> > +
On 07/07/17 12:46, Thomas Gleixner wrote:
> On Fri, 7 Jul 2017, Juri Lelli wrote:
> > How about SCHED_FLAG_SUGOV then?
>
> I know sugo della carne, but what's sugo V?
>
Right.. can't really help not thinking about the same (especially close
to lunch) :)
But
Hi,
On 07/07/17 14:28, Viresh Kumar wrote:
> On 05-07-17, 09:59, Juri Lelli wrote:
> > To be able to treat utilization signals of different scheduling classes
> > in different ways (e.g., CFS signal might be stale while DEADLINE signal
> > is never stale by design) we ne
Hi Viresh,
On 18/07/17 10:24, Viresh Kumar wrote:
> sg_cpu->last_update is always updated right after we call
> sugov_set_iowait_boost() and its better to update it from that routine
> itself. This makes it more readable.
>
> Signed-off-by: Viresh Kumar
> ---
> kernel/sched/cpufreq_schedutil.c
On 18/07/17 16:55, Viresh Kumar wrote:
> On 18-07-17, 12:20, Juri Lelli wrote:
> > Hi Viresh,
> >
> > On 18/07/17 10:24, Viresh Kumar wrote:
[...]
> >
> > It actually belongs here, IMHO. We update other fields (util, max,
> > flags)
>
> Yeah, becau
Hi,
On 18/07/17 11:15, Viresh Kumar wrote:
> On 17-07-17, 10:35, Joel Fernandes wrote:
> > On Mon, Jul 17, 2017 at 1:04 AM, Viresh Kumar
> > wrote:
> > > On 16-07-17, 01:04, Joel Fernandes wrote:
>
> > >> + if (sg_cpu->iowait_boost_pending) {
> > >> + sg_cpu->iowait_boost_pendin
On 19/07/17 09:21, Peter Zijlstra wrote:
> On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote:
> > @@ -1156,9 +1157,26 @@ static void update_curr_dl(struct rq *rq)
> > if (unlikely(dl_entity_is_special(dl_se)))
> > return;
> >
> &
On 19/07/17 13:00, Peter Zijlstra wrote:
> On Wed, Jul 19, 2017 at 10:20:29AM +0100, Juri Lelli wrote:
> > On 19/07/17 09:21, Peter Zijlstra wrote:
> > > On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote:
> > > > @@ -1156,9 +1157,26 @@ static voi
On 16/02/18 08:25, Christopher DÃaz Riveros wrote:
> El vie, 16-02-2018 a las 10:44 +0100, Juri Lelli escribió:
> > On 15/02/18 17:52, Peter Zijlstra wrote:
> > > On Thu, Feb 15, 2018 at 10:43:18AM -0500, Christopher Diaz Riveros
> > > wrote:
> >
> >
Hi Mathieu,
On 13/02/18 13:32, Mathieu Poirier wrote:
> No synchronisation mechanism exist between the cpuset subsystem and calls
> to function __sched_setscheduler(). As such it is possible that new root
> domains are created on the cpuset side while a deadline acceptance test
> is carried out i
On 14/02/18 11:36, Juri Lelli wrote:
> Hi Mathieu,
>
> On 13/02/18 13:32, Mathieu Poirier wrote:
> > No synchronisation mechanism exist between the cpuset subsystem and calls
> > to function __sched_setscheduler(). As such it is possible that new root
> > domains are
On 14/02/18 11:49, Juri Lelli wrote:
> On 14/02/18 11:36, Juri Lelli wrote:
> > Hi Mathieu,
> >
> > On 13/02/18 13:32, Mathieu Poirier wrote:
> > > No synchronisation mechanism exist between the cpuset subsystem and calls
> > > to function __sched_setschedu
On 14/02/18 08:33, Mathieu Poirier wrote:
> On 14 February 2018 at 04:27, Juri Lelli wrote:
> > On 14/02/18 11:49, Juri Lelli wrote:
> >> On 14/02/18 11:36, Juri Lelli wrote:
> >> > Hi Mathieu,
> >> >
> >> > On 13/02/18 13:32, Mathieu Poir
On 14/02/18 17:31, Juri Lelli wrote:
[...]
> Still grabbing it is a no-go, as do_sched_setscheduler calls
> sched_setscheduler from inside an RCU read-side critical section.
I was then actually thinking that trylocking might do.. not sure however
if failing with -EBUSY in the contended c
On 15/02/18 11:33, Juri Lelli wrote:
> On 14/02/18 17:31, Juri Lelli wrote:
>
> [...]
>
> > Still grabbing it is a no-go, as do_sched_setscheduler calls
> > sched_setscheduler from inside an RCU read-side critical section.
>
> I was then actually thinking that
Hi,
On 15/02/18 16:20, Morten Rasmussen wrote:
> From: Valentin Schneider
>
> The name "overload" is not very explicit, especially since it doesn't
> use any concept of "load" coming from load-tracking signals. For now it
> simply tracks if any of the CPUs in root_domain has more than one
> runn
On 15/02/18 17:52, Peter Zijlstra wrote:
> On Thu, Feb 15, 2018 at 10:43:18AM -0500, Christopher Diaz Riveros wrote:
[...]
> > @@ -437,20 +437,28 @@ struct sched_dl_entity {
> > * during sched_setattr(), they will remain the same until
> > * the next sched_setattr().
> > */
> > -
Hi,
On 09/02/18 11:36, Rafael J. Wysocki wrote:
> On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote:
> > Hi Viresh,
> >
> > Il 09/02/2018 04:51, Viresh Kumar ha scritto:
> > > On 08-02-18, 18:01, Claudio Scordino wrote:
> > >> When the SCHED_DEADLINE scheduling class increases the
On 09/02/18 12:04, Rafael J. Wysocki wrote:
> On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli wrote:
> > Hi,
> >
> > On 09/02/18 11:36, Rafael J. Wysocki wrote:
> >> On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote:
> >> > Hi Viresh,
> >
On 09/02/18 12:37, Rafael J. Wysocki wrote:
> On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli wrote:
> > On 09/02/18 12:04, Rafael J. Wysocki wrote:
> >> On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli wrote:
> >> > Hi,
> >> >
> >> > On 09/0
On 09/02/18 13:08, Rafael J. Wysocki wrote:
> On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli wrote:
> > On 09/02/18 12:37, Rafael J. Wysocki wrote:
> >> On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli wrote:
> >> > On 09/02/18 12:04, Rafael J. Wysocki wrote:
> >
On 09/02/18 13:56, Rafael J. Wysocki wrote:
> On Fri, Feb 9, 2018 at 1:52 PM, Juri Lelli wrote:
> > On 09/02/18 13:08, Rafael J. Wysocki wrote:
> >> On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli wrote:
[...]
> >> > My impression is that rate limit helps
Commit 3ca0ff571b09 ("locking/mutex: Rework mutex::owner") reworked the
basic mutex implementation to deal with several problems. Documentation
was however left unchanged and became stale.
Update mutex-design.txt to reflect changes introduced by the above commit.
Signed-off-by: Juri
Hi Mathieu,
On 01/02/18 09:51, Mathieu Poirier wrote:
> Introducing function partition_sched_domains_locked() by taking
> the mutex locking code out of the original function. That way
> the work done by partition_sched_domains_locked() can be reused
> without dropping the mutex lock.
>
> This pa
Hi Mathieu,
On 01/02/18 09:51, Mathieu Poirier wrote:
> When the topology of root domains is modified by CPUset or CPUhotplug
> operations information about the current deadline bandwidth held in the
> root domain is lost.
>
> This patch address the issue by recalculating the lost deadline
> band
Hi Mathieu,
On 01/02/18 09:51, Mathieu Poirier wrote:
> When considering to move a task to the DL policy we need to make sure
> the CPUs it is allowed to run on matches the CPUs of the root domains of
> the runqueue it is currently assigned to. Otherwise the task will be
> allowed to roam on CPUs
Hi Steve,
On 02/02/18 18:04, Steven Rostedt wrote:
>
> At Kernel Summit back in October, we tried to bring up trace markers, which
> would be nops within the kernel proper, that would allow modules to hook
> arbitrary trace events to them. The reaction to this proposal was less than
> favorable.
Hi Steve,
On 03/02/18 16:17, Steven Rostedt wrote:
> On Sat, 3 Feb 2018 12:52:08 -0800
> Alexei Starovoitov wrote:
>
> > It's a user space job.
>
> BTW, I asked around at DevConf.cz, and nobody I talked with (besides
> Arnaldo), have used eBPF. The "path to hello world" is quite high. This
> in
(rt_runtime_us/rt_period_us)
# cpu.dl_total_bw : current total (across CPUs) amount of bandwidth
allocated by the group (sum of tasks bandwidth)
- father/children/siblings rules are the same as for RT
Signed-off-by: Juri Lelli
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc
[1] https://lkml.org/lkml/2010/2/28/119
[2] https://lwn.net/Articles/718645/
Juri Lelli (3):
sched/deadline: merge dl_bw into dl_bandwidth
sched/deadline: add task groups bandwidth management support
Documentation/scheduler/sched-deadline: add info about cgroup support
Documentation/sched
Add documentation for SCHED_DEADLINE cgroup support (CONFIG_DEADLINE_
GROUP_SCHED config option).
Signed-off-by: Juri Lelli
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Tejun Heo
Cc: Jonathan Corbet
Cc: Luca Abeni
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
Documentation
ingle rt_bandwidth).
Signed-off-by: Juri Lelli
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Luca Abeni
Cc: linux-kernel@vger.kernel.org
---
kernel/sched/core.c | 2 +-
kernel/sched/deadline.c | 84 +++--
kernel/sched/debug.c| 6 ++--
kernel/sched/sc
Hi,
On 12/02/18 08:47, Tejun Heo wrote:
> Hello,
>
> On Mon, Feb 12, 2018 at 02:40:29PM +0100, Juri Lelli wrote:
> > - implementation _is not_ hierarchical: only single/plain DEADLINE entities
> >can be handled, and they get scheduled at root rq level
>
> This us
On 12/02/18 12:34, Steven Rostedt wrote:
> On Mon, 12 Feb 2018 14:40:28 +0100
> Juri Lelli wrote:
>
> > + * - dl_bw (< 100%) is the bandwidth of the system (domain) on each CPU;
> > + * - dl_total_bw array contains the currently allocated bandwidth on the
> > + *
On 12/02/18 13:02, Steven Rostedt wrote:
> On Mon, 12 Feb 2018 18:43:12 +0100
> Juri Lelli wrote:
>
> > However, this surely needs to be fixed here. It's tracking the sum of
> > all tasks' (across CPUs) bandwidth admitted on the system, so that's why
> >
Commit d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation") removed
reclaim_fs lockdep STATE.
Reflect the change in documentation.
While we are at it, also clarify formula to calculate number of state
bits.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc
Add section about annotations that can be used to perform additional runtime
checking of locking correctness: assert that certain locks are held and
prevent accidental unlocking.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: linux-kernel@vger.kernel.org
pretty new and maybe got unnoticed
outside of the scheduler?).
Best,
- Juri
Juri Lelli (2):
Documentation/locking/lockdep: update info about states
Documentation/locking/lockdep: Add section about available annotations
Documentation/locking/lockdep-design.txt | 51
> Reviewed-by: Jiang Biao
> Suggested-by: Peter Zijlstra
Acked-by: Juri Lelli
Thanks!
- Juri
On 05/02/18 11:11, Mathieu Poirier wrote:
> On 2 February 2018 at 03:19, Juri Lelli wrote:
> > Hi Mathieu,
> >
> > On 01/02/18 09:51, Mathieu Poirier wrote:
> >> Introducing function partition_sched_domains_locked() by taking
> >> the mutex locking code
ted topics/presentations will be sent out on
23rd of December 2017.
.:: ORGANISERS (in alphabetical order)
Luca Abeni (SSSA)
Patrick Bellasi (Arm)
Tommaso Cucinotta (SSSA)
Dietmar Eggemann (Arm)
Sudeep Holla (Arm)
Juri Lelli (Red Hat)
Lorenzo Pieralisi (Arm)
Morten Rasmussen (Arm)
Claudio Scordino (Evidence SRL)
On 20/12/17 15:47, Rafael J. Wysocki wrote:
> On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote:
> > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > On 20-Dec 09:31, Peter Zijlstra wrote:
> >
> > > > Didn't juri have patches to make DL do something sane? Bu
On 20/12/17 16:30, Peter Zijlstra wrote:
[...]
> @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> if (delta_ns > TICK_NSEC) {
> j_sg_cpu->iowait_boost = 0;
> j_sg_cpu->iowait_boost_pending = false;
> - j_
r Eggemann (Arm)
Sudeep Holla (Arm)
Juri Lelli (Red Hat)
Lorenzo Pieralisi (Arm)
Morten Rasmussen (Arm)
Claudio Scordino (Evidence SRL)
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
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max;
> > > s64 del
On 22/12/17 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +, 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;
> >
> > AFAIU global is only the admis
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 +, 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 o
On 22/12/17 12:50, Patrick Bellasi wrote:
> 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 +, Patrick Bellasi wrote:
> > > > >
Hi,
On 05/12/17 11:55, Patrick Bellasi wrote:
> Hi Juri,
>
> On 04-Dec 11:23, Juri Lelli wrote:
> [...]
>
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index de1ad1fffbdc..c22457868ee6 100644
> > --- a/ker
Hi,
On 05/12/17 15:09, Patrick Bellasi wrote:
> Hi Juri,
>
[...]
> > static void sugov_get_util(unsigned long *util, unsigned long *max, int
> > cpu)
> > {
> > struct rq *rq = cpu_rq(cpu);
> > - unsigned long cfs_max;
> > + unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_
Hi,
On 05/12/17 15:17, Patrick Bellasi wrote:
> Hi Juri,
>
> On 04-Dec 11:23, Juri Lelli wrote:
> > From: Juri Lelli
> >
> > To be able to treat utilization signals of different scheduling classes
> > in different ways (e.g., CFS signal might be stale while D
On 05/12/17 16:34, Patrick Bellasi wrote:
> 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
> >
Hi Viresh,
On 12/12/17 17:07, Viresh Kumar wrote:
[...]
> From: Viresh Kumar
> Date: Tue, 12 Dec 2017 15:43:26 +0530
> Subject: [PATCH] sched: Keep track of cpufreq utilization update flags
>
> Currently the schedutil governor overwrites the sg_cpu->flags field on
> every call to the utilizati
On 12/12/17 20:10, Viresh Kumar wrote:
> On 12-12-17, 14:38, Juri Lelli wrote:
> > Hi Viresh,
> >
> > On 12/12/17 17:07, Viresh Kumar wrote:
> >
> > [...]
> >
> > > From: Viresh Kumar
> > > Date: Tue, 12 Dec 2017 15:43:26 +0530
> &
te
> flags anyway.
>
> Initialize it to 0.
>
> Change-Id: I028dbb40c5c242cff52fe1b14aeaff37f29a2f8d
Without ^
> Signed-off-by: Viresh Kumar
Reviewed-by: Juri Lelli
Best,
- Juri
T (1U << 2)
> +#define SCHED_CPUFREQ_CFS(1U << 2)
This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump
up frequency, while you are adding CFS for the sake of simmetry, right?
And with my patches DL will hopefully soon be in the same situation.
If my understanding is correct, maybe add a comment?
Apart from this, patch looks good to me; couldn't test it though, sorry.
Reviewed-by: Juri Lelli
Thanks,
- Juri
Hi,
On 13/12/17 15:23, Viresh Kumar wrote:
> We are already passing sg_cpu as argument to sugov_set_iowait_boost()
> helper and the same can be used to retrieve the flags value. Get rid of
> the redundant argument.
>
> Signed-off-by: Viresh Kumar
Reviewed-by: Juri Lelli
Best,
- Juri
Hi,
On 13/12/17 15:23, Viresh Kumar wrote:
> sugov_update_shared() may get called to clear the scheduling class flags
> and we would return immediately in that case. Calling sugov_get_util()
> in that case isn't going to be of any use then. Move invocation of
> sugov_get_util() after the clear fla
Hi,
On 22/08/17 14:53, Byungchul Park wrote:
> On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote:
> > Hi,
> > On 18/08/17 17:21, Byungchul Park wrote:
> > > It would be better to try to check other siblings first if
> > > SD_PREFER_SIBLING is flag
eady loaded core.
> + * of cpu3 that is fully loaded.
> + *
> + * We have to do the best if possible, but choose the second
> + * best here since that is too expensive to adopt.
> + */
I'd also modify this last paragraph with something like:
"Doing it 'right' is difficult and expensive. The current solution is an
acceptable approximation."
Apart from these minor points, patch looks ok to me.
Acked-by: Juri Lelli
Best,
- Juri
Hi,
On 24/08/17 09:53, Luca Abeni wrote:
> On Wed, 23 Aug 2017 13:47:13 -0600
> Mathieu Poirier wrote:
> > >> This is a renewed attempt at fixing a problem reported by Steve Rostedt
> > >> [1]
> > >> where DL bandwidth accounting is not recomputed after CPUset and
> > >> CPUhotplug
> > >> opera
Hi,
On 18/08/17 17:21, Byungchul Park wrote:
> It would be better to try to check other siblings first if
> SD_PREFER_SIBLING is flaged when pushing tasks - migration.
>
> Signed-off-by: Byungchul Park
Mmm, this looks like Peter's proposed patch, maybe add (at least) a
Suggested-by: him ?
http
On 21/08/17 15:56, Peter Zijlstra wrote:
> On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote:
>
> > Also, I'm not sure what Peter meant with
> >
> > "But still this isn't quite right, because when we consider this for SMT
> > (as was the int
On 22/06/17 19:58, Viresh Kumar wrote:
> On 22-06-17, 10:39, Juri Lelli wrote:
> > Hi,
> >
> > On 21/06/17 10:16, Viresh Kumar wrote:
> > > Use the standard way of returning errors instead of returning 0(failure)
> > > OR 1(success) and making it hard to r
On 22/06/17 19:59, Viresh Kumar wrote:
> On 22-06-17, 10:44, Juri Lelli wrote:
> > Hi,
> >
> > On 21/06/17 10:16, Viresh Kumar wrote:
> > > We can reuse "cap_parsing_failed" instead of keeping an additional
> > > variable here.
> > >
&
On 31/05/17 12:30, Peter Zijlstra wrote:
> On Wed, May 31, 2017 at 11:40:47AM +0200, Peter Zijlstra wrote:
> > On Wed, May 24, 2017 at 11:00:51AM +0200, Vincent Guittot wrote:
> > > schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs
> > > tasks are running. When the CPU is ov
Reference to cpu capacity binding has a wrong number. Fix it.
Reported-by: Lorenzo Pieralisi
Signed-off-by: Juri Lelli
Acked-by: Rob Herring
Acked-by: Russell King
---
Documentation/devicetree/bindings/arm/cpus.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
c.info/?l=linux-kernel&m=148483680119355&w=2
v2 - https://marc.info/?l=linux-kernel&m=148663344018205&w=2
v3 - http://marc.info/?l=linux-kernel&m=149062080701399&w=2
v4 - https://marc.info/?l=linux-kernel&m=149269955206646&w=2
Juri Lelli (7):
Documenta
parse_cpu_capacity() has to return 0 on failure, but it currently returns
1 instead if raw_capacity kcalloc failed.
Fix it (by directly returning 0).
Cc: Russell King
Reported-by: Morten Rasmussen
Fixes: 06073ee26775 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT')
Signed-of
The sysfs cpu_capacity entry for each CPU has nothing to do with
PROC_FS, nor it's in /proc/sys path.
Remove such ifdef.
Cc: Russell King
Reported-and-suggested-by: Sudeep Holla
Fixes: 7e5930aaef5d ('ARM: 8622/3: add sysfs cpu_capacity attribute')
Signed-off-by: Juri Lelli
Ac
additions.
Suggested-by: Will Deacon
Suggested-by: Mark Rutland
Suggested-by: Catalin Marinas
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Greg Kroah-Hartman
Signed-off-by: Juri Lelli
Acked-by: Russell King
Acked-by: Catalin Marinas
Acked-by: Greg Kroah-Hartman
---
arch/arm
Create a new header file (include/linux/arch_topology.h) and put there
declarations of interfaces used by arm, arm64 and drivers code.
Signed-off-by: Juri Lelli
Acked-by: Russell King
Acked-by: Catalin Marinas
Acked-by: Greg Kroah-Hartman
---
arch/arm/kernel/topology.c| 7 +--
arch
) means cap_from _dt is set to false.
For arm64 we can simply check if raw_capacity points to something,
which is not if capacity parsing has failed.
Suggested-by: Morten Rasmussen
Signed-off-by: Juri Lelli
Acked-by: Russell King
Acked-by: Catalin Marinas
Acked-by: Greg Kroah-Hartman
---
arch
interfaces.
Signed-off-by: Juri Lelli
Acked-by: Russell King
Acked-by: Catalin Marinas
---
Changes from v4:
- as per discussion with Greg, Dietmar and Morten (off-line)
the interface function have been renamed as
s/atd_normalize_cpu_capacity/topology_normalize_cpu_scale/
s/atd_parse_cp
On 16/05/17 15:52, Byungchul Park wrote:
> On Fri, May 12, 2017 at 10:25:30AM -0400, Steven Rostedt wrote:
> > On Fri, 12 May 2017 14:48:45 +0900
> > Byungchul Park wrote:
> >
> > > cpudl.elements is an instance that should be protected with a spin lock.
> > > Without it, the code would be insane
: Claudio Scordino
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
---
include/linux/sched/cpufreq.h| 2 --
kernel/sched/cpufreq_schedutil.c | 13 ++---
2 files changed, 6 insertions(+), 9 deletions(-)
diff
ed-by: Claudio Scordino
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
---
kernel/sched/deadline.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
d-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
Cc: Claudio Scordino
---
Changes from RFD
- discard CFS contribution only as stale (as suggested by Rafael)
---
kernel/sched/cpufreq_schedutil.c | 17 +++--
1 file change
specified profiling the task execution at max frequency on
biggest capacity core) gets thus scaled accordingly.
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Luca Abeni
Cc: Claudio Scordino
---
Changes from RFD
- either apply
1101 - 1200 of 1334 matches
Mail list logo
