Hi,
On 19/10/2018 09:02, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
[...]
> So what unifies RT and DL utilization is that those are all direct task
> loads independent of external factors.
>
> Thermal load is more of a complex physical property of the combination of
> various internal
* Thara Gopinath wrote:
> > Yeah, so I'd definitely suggest to not integrate this averaging into
> > pelt.c in the fashion presented, because:
> >
> > - This couples your thermal throttling averaging to the PELT decay
> >half-time AFAICS, which would break the other user every time the
>
On 10/18/2018 02:48 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
>> On 10/16/2018 03:33 AM, Ingo Molnar wrote:
>>>
>>> * Thara Gopinath wrote:
>>>
>> Regarding testing, basic build, boot and sanity testing have been
>> performed on hikey960 mainline kernel with debian file syste
On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar wrote:
>
>
> * Rafael J. Wysocki wrote:
>
> > > The only long term maintainable solution is to move all high level
> > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > > which has been done to a fair degree already in the past
Hi Vincent,
On 10/16/2018 07:11 PM, Vincent Guittot wrote:
> Hi Lukasz,
>
> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>
>>
>>
>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
>>> Hello Lukasz,
>>>
>>> On 10/10/2018 11:35 AM, Lukasz Luba wrote:
Hi Thara,
I have run it on Ex
On 10/17/2018 06:24 PM, Thara Gopinath wrote:
> On 10/16/2018 01:11 PM, Vincent Guittot wrote:
>> Hi Lukasz,
>>
>> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>>
>>>
>>>
>>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba wrote
* Rafael J. Wysocki wrote:
> > The only long term maintainable solution is to move all high level
> > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > which has been done to a fair degree already in the past ~2 years - but
> > it's unclear to me to what extent this is tr
On Thu, Oct 18, 2018 at 8:48 AM Ingo Molnar wrote:
>
>
> * Thara Gopinath wrote:
>
> > On 10/16/2018 03:33 AM, Ingo Molnar wrote:
> > >
> > > * Thara Gopinath wrote:
> > >
> > Regarding testing, basic build, boot and sanity testing have been
> > performed on hikey960 mainline kernel wi
* Thara Gopinath wrote:
> On 10/16/2018 03:33 AM, Ingo Molnar wrote:
> >
> > * Thara Gopinath wrote:
> >
> Regarding testing, basic build, boot and sanity testing have been
> performed on hikey960 mainline kernel with debian file system.
> Further aobench (An occlusion rendere
On 10/16/2018 01:11 PM, Vincent Guittot wrote:
> Hi Lukasz,
>
> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>
>>
>>
>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
>>> Hello Lukasz,
>>>
>>> On 10/10/2018 11:35 AM, Lukasz Luba wrote:
Hi Thara,
I have run it on Exynos5433 main
On 10/16/2018 03:33 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
Regarding testing, basic build, boot and sanity testing have been
performed on hikey960 mainline kernel with debian file system.
Further aobench (An occlusion renderer for benchmarking realworld
floating
Hi Lukasz,
On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>
>
>
> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
> > Hello Lukasz,
> >
> > On 10/10/2018 11:35 AM, Lukasz Luba wrote:
> >> Hi Thara,
> >>
> >> I have run it on Exynos5433 mainline.
> >> When it is enabled with step_wise thermal gove
On 10/16/2018 09:33 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
Regarding testing, basic build, boot and sanity testing have been
performed on hikey960 mainline kernel with debian file system.
Further aobench (An occlusion renderer for benchmarking realworld
floati
* Thara Gopinath wrote:
> >> Regarding testing, basic build, boot and sanity testing have been
> >> performed on hikey960 mainline kernel with debian file system.
> >> Further aobench (An occlusion renderer for benchmarking realworld
> >> floating point performance) showed the following results
On 10/11/2018 10:23 AM, Daniel Lezcano wrote:
> On 11/10/2018 09:35, Lukasz Luba wrote:
>> Hi Daniel,
>>
>> On 10/10/2018 06:54 PM, Daniel Lezcano wrote:
>>> On 10/10/2018 17:35, Lukasz Luba wrote:
Hi Thara,
I have run it on Exynos5433 mainline.
When it is enabled with step_wi
On 10/10/2018 07:30 PM, Thara Gopinath wrote:
> Hello Lukasz,
>
> On 10/10/2018 11:35 AM, Lukasz Luba wrote:
>> Hi Thara,
>>
>> I have run it on Exynos5433 mainline.
>> When it is enabled with step_wise thermal governor,
>> some of my tests are showing ~30-50% regression (i.e. hackbench),
>> dh
On 11/10/2018 09:35, Lukasz Luba wrote:
> Hi Daniel,
>
> On 10/10/2018 06:54 PM, Daniel Lezcano wrote:
>> On 10/10/2018 17:35, Lukasz Luba wrote:
>>> Hi Thara,
>>>
>>> I have run it on Exynos5433 mainline.
>>> When it is enabled with step_wise thermal governor,
>>> some of my tests are showing ~30
Hi Daniel,
On 10/10/2018 06:54 PM, Daniel Lezcano wrote:
> On 10/10/2018 17:35, Lukasz Luba wrote:
>> Hi Thara,
>>
>> I have run it on Exynos5433 mainline.
>> When it is enabled with step_wise thermal governor,
>> some of my tests are showing ~30-50% regression (i.e. hackbench),
>> dhrystone ~10%.
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
That is interesting. If I understand correctl
On 10/10/2018 09:34 AM, Juri Lelli wrote:
> On 10/10/18 15:08, Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>>>
>>> On 10/10/18 14:34, Vincent Guittot wrote:
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04, Vincen
Hello Quentin,
On 10/10/2018 05:55 AM, Quentin Perret wrote:
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
>> The problem with reflecting directly the capping is that it happens
>> far more often than the pace at which cpu_capacity_orig is updated in
>> the
On 10/10/2018 17:35, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
>
> Could you tell me which thermal governor was used in your c
Hi guys,
On 10/10/18 14:47, Quentin Perret wrote:
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
>>>
>>> On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
This patchset doesn't touch cpu_capacit
Hello Ingo,
Thank you for the review.
On 10/10/2018 02:17 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
>> Thermal governors can respond to an overheat event for a cpu by
>> capping the cpu's maximum possible frequency. This in turn
>> means that the maximum available compute capacity of
Hi Thara,
I have run it on Exynos5433 mainline.
When it is enabled with step_wise thermal governor,
some of my tests are showing ~30-50% regression (i.e. hackbench),
dhrystone ~10%.
Could you tell me which thermal governor was used in your case?
Please also share the name of that benchmark, i wil
On Wed, 10 Oct 2018 at 15:48, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
> > >
> > > On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> > > > This patchset doesn't touch
Hello Javi,
Thanks for the interest.
On 10/10/2018 01:44 AM, Javi Merino wrote:
> On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
>> Thermal governors can respond to an overheat event for a cpu by
>> capping the cpu's maximum possible frequency. This in turn
>> means that the maxi
On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
> >
> > On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> > > This patchset doesn't touch cpu_capacity_orig and doesn't need to as
> > > it assume that t
On Wed, 10 Oct 2018 at 15:35, Juri Lelli wrote:
>
> On 10/10/18 15:08, Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:34, Vincent Guittot wrote:
> > > > Hi Juri,
> > > >
> > > > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > > > >
> >
On 10/10/18 15:08, Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
> >
> > On 10/10/18 14:34, Vincent Guittot wrote:
> > > Hi Juri,
> > >
> > > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > > >
> > > > On 10/10/18 14:04, Vincent Guittot wrote:
> > > >
> > > > [...]
On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> > This patchset doesn't touch cpu_capacity_orig and doesn't need to as
> > it assume that the max capacity is unchanged but some capacity is
> > momentary stolen by therm
On Wednesday 10 Oct 2018 at 14:50:33 (+0200), Juri Lelli wrote:
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with RT,
On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with RT, the cfs utili
On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> This patchset doesn't touch cpu_capacity_orig and doesn't need to as
> it assume that the max capacity is unchanged but some capacity is
> momentary stolen by thermal.
> If you want to reflect immediately all thermal capping c
On 10/10/18 14:34, Vincent Guittot wrote:
> Hi Juri,
>
> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> >
> > On 10/10/18 14:04, Vincent Guittot wrote:
> >
> > [...]
> >
> > > The problem was the same with RT, the cfs utilization was lower than
> > > reality because RT steals soem cycle to CF
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04, Vincent Guittot wrote:
>
> [...]
>
> > The problem was the same with RT, the cfs utilization was lower than
> > reality because RT steals soem cycle to CFS
> > So schedutil was selecting a lower frequency when cfs wa
On 10/10/18 14:04, Vincent Guittot wrote:
[...]
> The problem was the same with RT, the cfs utilization was lower than
> reality because RT steals soem cycle to CFS
> So schedutil was selecting a lower frequency when cfs was running
> whereas the CPU was fully used.
> The same can happen with the
On Wed, 10 Oct 2018 at 12:36, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> > >
> > > Hi Vincent,
> > >
> > > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > > The
On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> >
> > Hi Vincent,
> >
> > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > The problem with reflecting directly the capping is that it happens
> >
On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
>
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > The problem with reflecting directly the capping is that it happens
> > far more often than the pace at which cpu_capacity_orig is updated in
> > the sch
Hi Vincent,
On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> The problem with reflecting directly the capping is that it happens
> far more often than the pace at which cpu_capacity_orig is updated in
> the scheduler.
Hmm, how can you be so sure ? That most likely depends on
On Wed, 10 Oct 2018 at 10:29, Quentin Perret wrote:
>
> Hi Thara,
>
> On Wednesday 10 Oct 2018 at 08:17:51 (+0200), Ingo Molnar wrote:
> >
> > * Thara Gopinath wrote:
> >
> > > Thermal governors can respond to an overheat event for a cpu by
> > > capping the cpu's maximum possible frequency. This
Hi Thara,
On Wednesday 10 Oct 2018 at 08:17:51 (+0200), Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
> > Thermal governors can respond to an overheat event for a cpu by
> > capping the cpu's maximum possible frequency. This in turn
> > means that the maximum available compute capacity of th
* Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, in event of maximum
> frequency cappi
On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, i
45 matches
Mail list logo
