Hi Qais,
On Tue, 23 Jun 2020 at 17:44, Qais Yousef wrote:
>
> Hi Vincent
>
> On 06/11/20 14:01, Vincent Guittot wrote:
> > On Thu, 11 Jun 2020 at 12:24, Qais Yousef wrote:
>
> [...]
>
> > > > Strange because I have been able to trace them.
> > >
> > > On your arm platform? I can certainly see th
Hi Vincent
On 06/11/20 14:01, Vincent Guittot wrote:
> On Thu, 11 Jun 2020 at 12:24, Qais Yousef wrote:
[...]
> > > Strange because I have been able to trace them.
> >
> > On your arm platform? I can certainly see them on x86.
>
> yes on my arm platform
Sorry for not getting back to you earli
[snip]
Hi Mel and Qais,
I was able to synthesize results from some experiments which I conducted
on my machine. You can find them below with descriptions.
1. Description of the configuration and hardware
My machine is a HP server 2 socket 24 CPUs X86 64bit
(4 NUMA nodes, AMD Opteron 6174, L2
On 06/11/20 11:58, Qais Yousef wrote:
[...]
>
> nouclam nouclamp
> uclam uclamp uclamp.disable
> uclamp uclamp uclamp
>
On Thu, 11 Jun 2020 at 12:24, Qais Yousef wrote:
>
> On 06/09/20 19:10, Vincent Guittot wrote:
> > On Mon, 8 Jun 2020 at 14:31, Qais Yousef wrote:
> > >
> > > On 06/04/20 14:14, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > I have tried your patch and I don't see any difference compared
On 06/04/20 14:40, Mel Gorman wrote:
> On Wed, Jun 03, 2020 at 01:41:13PM +0100, Qais Yousef wrote:
> > > > netperf-udp
> > > > ./5.7.0-rc7./5.7.0-rc7
> > > > ./5.7.0-rc7
> > > > without-clamp with-cla
On 06/09/20 19:10, Vincent Guittot wrote:
> On Mon, 8 Jun 2020 at 14:31, Qais Yousef wrote:
> >
> > On 06/04/20 14:14, Vincent Guittot wrote:
> >
> > [...]
> >
> > > I have tried your patch and I don't see any difference compared to
> > > previous tests. Let me give you more details of my setup:
>
On 06/08/20 10:44, Steven Rostedt wrote:
> On Mon, 8 Jun 2020 13:31:03 +0100
> Qais Yousef wrote:
>
> > I admit I don't know how much of these numbers is ftrace overhead. When
> > trying
>
> Note, if you want to get a better idea of how long a function runs, put it
> into set_ftrace_filter, and
On Mon, 8 Jun 2020 at 14:31, Qais Yousef wrote:
>
> On 06/04/20 14:14, Vincent Guittot wrote:
>
> [...]
>
> > I have tried your patch and I don't see any difference compared to
> > previous tests. Let me give you more details of my setup:
> > I create 3 levels of cgroups and usually run the tests
H Qais,
Sorry for the late reply.
On Fri, 5 Jun 2020 at 12:45, Qais Yousef wrote:
>
> On 06/04/20 14:14, Vincent Guittot wrote:
> > I have tried your patch and I don't see any difference compared to
> > previous tests. Let me give you more details of my setup:
> > I create 3 levels of cgroups an
On Mon, 8 Jun 2020 13:31:03 +0100
Qais Yousef wrote:
> I admit I don't know how much of these numbers is ftrace overhead. When trying
Note, if you want to get a better idea of how long a function runs, put it
into set_ftrace_filter, and then trace it. That way you remove the overhead
of the func
On 08/06/20 13:31, Qais Yousef wrote:
> With uclamp enabled but no fair group I get
>
> *** uclamp enabled/fair group disabled ***
>
> # Executed 5 pipe operations between two threads
>Total time: 0.856 [sec]
>
>17.125740 usecs/op
>58391 ops/sec
>
On 06/04/20 14:14, Vincent Guittot wrote:
[...]
> I have tried your patch and I don't see any difference compared to
> previous tests. Let me give you more details of my setup:
> I create 3 levels of cgroups and usually run the tests in the 4 levels
> (which includes root). The result above are f
On Fri, Jun 05, 2020 at 13:32:04 +0200, Qais Yousef
wrote...
> On 06/05/20 09:55, Patrick Bellasi wrote:
>> On Wed, Jun 03, 2020 at 18:52:00 +0200, Qais Yousef
>> wrote...
[...]
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index 0464569f26a7..9f48090eb926 100644
>> > --
On 06/05/20 09:55, Patrick Bellasi wrote:
>
> Hi Qais,
>
> On Wed, Jun 03, 2020 at 18:52:00 +0200, Qais Yousef
> wrote...
>
> > On 06/03/20 16:59, Vincent Guittot wrote:
> >> When I want to stress the fast path i usually use "perf bench sched pipe
> >> -T "
> >> The tip/sched/core on my arm o
On 06/04/20 14:40, Mel Gorman wrote:
> > > > The diffs are smaller than on openSUSE Leap 15.1 and some of the
> > > > uclamp taskgroup results are better?
> > > >
> > >
> > > I don't see the stddev and coeff but these look close to borderline.
> > > Sure, they are marked with a * so it passed a s
On 06/04/20 14:14, Vincent Guittot wrote:
> I have tried your patch and I don't see any difference compared to
> previous tests. Let me give you more details of my setup:
> I create 3 levels of cgroups and usually run the tests in the 4 levels
> (which includes root). The result above are for the r
Hi Qais,
On Wed, Jun 03, 2020 at 18:52:00 +0200, Qais Yousef
wrote...
> On 06/03/20 16:59, Vincent Guittot wrote:
>> When I want to stress the fast path i usually use "perf bench sched pipe -T "
>> The tip/sched/core on my arm octo core gives the following results for
>> 20 iterations of perf
On Wed, Jun 03, 2020 at 01:41:13PM +0100, Qais Yousef wrote:
> > > netperf-udp
> > > ./5.7.0-rc7./5.7.0-rc7
> > > ./5.7.0-rc7
> > > without-clamp with-clamp
> > > with-clamp-tskgrp
> > >
> > > H
On Wed, 3 Jun 2020 at 18:52, Qais Yousef wrote:
>
> On 06/03/20 16:59, Vincent Guittot wrote:
> > When I want to stress the fast path i usually use "perf bench sched pipe -T
> > "
> > The tip/sched/core on my arm octo core gives the following results for
> > 20 iterations of perf bench sched pipe
On 06/03/20 16:59, Vincent Guittot wrote:
> When I want to stress the fast path i usually use "perf bench sched pipe -T "
> The tip/sched/core on my arm octo core gives the following results for
> 20 iterations of perf bench sched pipe -T -l 5
>
> all uclamp config disabled 50035.4(+/- 0.334%
On Wed, 3 Jun 2020 at 12:10, Mel Gorman wrote:
>
> On Wed, Jun 03, 2020 at 10:29:22AM +0200, Patrick Bellasi wrote:
> >
> > Hi Dietmar,
> > thanks for sharing these numbers.
> >
> > On Tue, Jun 02, 2020 at 18:46:00 +0200, Dietmar Eggemann
> > wrote...
> >
> > [...]
> >
> > > I ran these tests on
On 06/03/20 10:40, Mel Gorman wrote:
> On Tue, Jun 02, 2020 at 06:46:00PM +0200, Dietmar Eggemann wrote:
> > On 29.05.20 12:08, Mel Gorman wrote:
> > > On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote:
> > >>> FWIW, I think you're referring to Mel's notice in OSPM regarding the
> > >
On Wed, Jun 03, 2020 at 10:29:22AM +0200, Patrick Bellasi wrote:
>
> Hi Dietmar,
> thanks for sharing these numbers.
>
> On Tue, Jun 02, 2020 at 18:46:00 +0200, Dietmar Eggemann
> wrote...
>
> [...]
>
> > I ran these tests on 'Ubuntu 18.04 Desktop' on Intel E5-2690 v2
> > (2 sockets * 10 core
On Tue, Jun 02, 2020 at 06:46:00PM +0200, Dietmar Eggemann wrote:
> On 29.05.20 12:08, Mel Gorman wrote:
> > On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote:
> >>> FWIW, I think you're referring to Mel's notice in OSPM regarding the
> >>> overhead.
> >>> Trying to see what goes on i
Hi Dietmar,
thanks for sharing these numbers.
On Tue, Jun 02, 2020 at 18:46:00 +0200, Dietmar Eggemann
wrote...
[...]
> I ran these tests on 'Ubuntu 18.04 Desktop' on Intel E5-2690 v2
> (2 sockets * 10 cores * 2 threads) with powersave governor as:
>
> $ numactl -N 0 ./run-mmtests.sh XXX
Gr
On 29.05.20 12:08, Mel Gorman wrote:
> On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote:
>>> FWIW, I think you're referring to Mel's notice in OSPM regarding the
>>> overhead.
>>> Trying to see what goes on in there.
>>
>> Indeed, that one. The fact that regular distros cannot enable
> > A lot of the uclamp functions appear to be inlined so it is not be
> > particularly obvious from a raw profile but it shows up in the annotated
> > profile in activate_task and dequeue_task for example. In the case of
> > dequeue_task, uclamp_rq_dec_id() is extremely expensive according to the
On 05/29/20 17:02, Mel Gorman wrote:
> On Fri, May 29, 2020 at 04:11:18PM +0100, Qais Yousef wrote:
> > > Elsewhere in the thread, I showed some results based on 5.7 so uclamp
> > > task group existed but I had it disabled. The uclamp related parts of
> > > the kconfig were
> > >
> > > # zgrep UCL
On 05/29/20 11:08, Mel Gorman wrote:
> On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote:
> > > FWIW, I think you're referring to Mel's notice in OSPM regarding the
> > > overhead.
> > > Trying to see what goes on in there.
> >
> > Indeed, that one. The fact that regular distros cann
On Fri, May 29, 2020 at 04:11:18PM +0100, Qais Yousef wrote:
> > Elsewhere in the thread, I showed some results based on 5.7 so uclamp
> > task group existed but I had it disabled. The uclamp related parts of
> > the kconfig were
> >
> > # zgrep UCLAMP kconfig-5.7.0-rc7-with-clamp.txt.gz
> > CONFI
On 05/29/20 11:21, Mel Gorman wrote:
> On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
> > > Indeed, that one. The fact that regular distros cannot enable this
> > > feature due to performance overhead is unfortunate. It means there is a
> > > lot less potential for this stuff.
> >
>
On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
> > Indeed, that one. The fact that regular distros cannot enable this
> > feature due to performance overhead is unfortunate. It means there is a
> > lot less potential for this stuff.
>
> I had a humble try to catch the overhead but wa
On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote:
> > FWIW, I think you're referring to Mel's notice in OSPM regarding the
> > overhead.
> > Trying to see what goes on in there.
>
> Indeed, that one. The fact that regular distros cannot enable this
> feature due to performance overh
On 05/28/20 20:29, Peter Zijlstra wrote:
> On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
>
> > In my head, the simpler version of
> >
> > if (rt_task(p) && !uc->user_defined)
> > // update_uclamp_min
> >
> > Is a single branch and write to cache, so should be fast.
On 28/05/2020 20:29, Peter Zijlstra wrote:
> On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
>
>> In my head, the simpler version of
>>
>> if (rt_task(p) && !uc->user_defined)
>> // update_uclamp_min
>>
>> Is a single branch and write to cache, so should be fast. I'm
[+Giovanni]
On Thu, May 28, 2020 at 20:29:14 +0200, Peter Zijlstra
wrote...
> On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
>> I had a humble try to catch the overhead but wasn't successful. The
>> observation
>> wasn't missed by us too then.
>
> Right, I remember us doing be
On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
> In my head, the simpler version of
>
> if (rt_task(p) && !uc->user_defined)
> // update_uclamp_min
>
> Is a single branch and write to cache, so should be fast. I'm failing to see
> how this could generate an over
On 05/28/20 18:11, Peter Zijlstra wrote:
> On Thu, May 28, 2020 at 04:58:01PM +0100, Qais Yousef wrote:
> > On 05/28/20 15:23, Peter Zijlstra wrote:
>
> > > So afaict this is directly added to the enqueue/dequeue path, and we've
> > > recently already had complaints that uclamp is too slow.
> >
>
On Thu, May 28, 2020 at 04:58:01PM +0100, Qais Yousef wrote:
> On 05/28/20 15:23, Peter Zijlstra wrote:
> > So afaict this is directly added to the enqueue/dequeue path, and we've
> > recently already had complaints that uclamp is too slow.
>
> I wanted to keep this function simpler.
Right; I ap
On 05/28/20 15:23, Peter Zijlstra wrote:
> On Mon, May 11, 2020 at 04:40:52PM +0100, Qais Yousef wrote:
> > +/*
> > + * By default RT tasks run at the maximum performance point/capacity of the
> > + * system. Uclamp enforces this by always setting UCLAMP_MIN of RT tasks to
> > + * SCHED_CAPACITY_SC
On Mon, May 11, 2020 at 04:40:52PM +0100, Qais Yousef wrote:
> +/*
> + * By default RT tasks run at the maximum performance point/capacity of the
> + * system. Uclamp enforces this by always setting UCLAMP_MIN of RT tasks to
> + * SCHED_CAPACITY_SCALE.
> + *
> + * This knob allows admins to change
On 05/18/20 10:31, Dietmar Eggemann wrote:
> On 11/05/2020 17:40, Qais Yousef wrote:
>
> [..]
>
> > @@ -790,6 +790,26 @@ unsigned int sysctl_sched_uclamp_util_min =
> > SCHED_CAPACITY_SCALE;
> > /* Max allowed maximum utilization */
> > unsigned int sysctl_sched_uclamp_util_max = SCHED_CAPACIT
On 11/05/2020 17:40, Qais Yousef wrote:
[..]
> @@ -790,6 +790,26 @@ unsigned int sysctl_sched_uclamp_util_min =
> SCHED_CAPACITY_SCALE;
> /* Max allowed maximum utilization */
> unsigned int sysctl_sched_uclamp_util_max = SCHED_CAPACITY_SCALE;
>
> +/*
> + * By default RT tasks run at the max
I Qais,
I see we are converging toward the final shape. :)
Function wise code looks ok to me now.
Lemme just point out few more remarks and possible nit-picks.
I guess at the end it's up to you to decide if you wanna follow up with
a v6 and to the maintainers to decide how picky they wanna be.
On 05/12/20 07:40, Pavan Kondeti wrote:
> On Mon, May 11, 2020 at 04:40:52PM +0100, Qais Yousef wrote:
> > RT tasks by default run at the highest capacity/performance level. When
> > uclamp is selected this default behavior is retained by enforcing the
> > requested uclamp.min (p->uclamp_req[UCLAMP
On Mon, May 11, 2020 at 04:40:52PM +0100, Qais Yousef wrote:
> RT tasks by default run at the highest capacity/performance level. When
> uclamp is selected this default behavior is retained by enforcing the
> requested uclamp.min (p->uclamp_req[UCLAMP_MIN]) of the RT tasks to be
> uclamp_none(UCLAM
Sorry I forgot to label this as v5 in the subject line.
--
Qais Yousef
On 05/11/20 16:40, Qais Yousef wrote:
> RT tasks by default run at the highest capacity/performance level. When
> uclamp is selected this default behavior is retained by enforcing the
> requested uclamp.min (p->uclamp_req[UCLA
RT tasks by default run at the highest capacity/performance level. When
uclamp is selected this default behavior is retained by enforcing the
requested uclamp.min (p->uclamp_req[UCLAMP_MIN]) of the RT tasks to be
uclamp_none(UCLAMP_MAX), which is SCHED_CAPACITY_SCALE; the maximum
value.
This is al
49 matches
Mail list logo
