On Sat, 29 Sep 2018 at 01:36, Dietmar Eggemann wrote:
>
> On 09/28/2018 06:10 PM, Steve Muckle wrote:
> > On 09/27/2018 05:43 PM, Wanpeng Li wrote:
> On your CPU4:
> scheduler_ipi()
> -> sched_ttwu_pending()
> -> ttwu_do_activate()=> p->sched_remote_wakeup should
On 09/28/2018 06:10 PM, Steve Muckle wrote:
On 09/27/2018 05:43 PM, Wanpeng Li wrote:
On your CPU4:
scheduler_ipi()
-> sched_ttwu_pending()
-> ttwu_do_activate() => p->sched_remote_wakeup should be
false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not
-> ttwu_activa
On 09/28/2018 02:43 AM, Wanpeng Li wrote:
On Thu, 27 Sep 2018 at 21:23, Dietmar Eggemann wrote:
On 09/27/2018 03:19 AM, Wanpeng Li wrote:
On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann wrote:
Hi,
On 09/26/2018 11:50 AM, Wanpeng Li wrote:
Hi Dietmar,
On Tue, 28 Aug 2018 at 22:55, Dietmar
On Fri, Sep 28, 2018 at 9:10 AM, 'Steve Muckle' via kernel-team
wrote:
> On 09/27/2018 05:43 PM, Wanpeng Li wrote:
On your CPU4:
scheduler_ipi()
-> sched_ttwu_pending()
-> ttwu_do_activate()=> p->sched_remote_wakeup should be
false, so ENQUEUE_WAKEUP is
On Wed, Sep 26, 2018 at 6:19 PM, Wanpeng Li wrote:
> On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann
> wrote:
>>
>> Hi,
>>
>> On 09/26/2018 11:50 AM, Wanpeng Li wrote:
>> > Hi Dietmar,
>> > On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann
>> > wrote:
>> >>
>> >> On 08/27/2018 12:14 PM, Peter Zijl
On 09/27/2018 05:43 PM, Wanpeng Li wrote:
On your CPU4:
scheduler_ipi()
-> sched_ttwu_pending()
-> ttwu_do_activate()=> p->sched_remote_wakeup should be
false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not
-> ttwu_activate()
-> activate_task()
On Thu, 27 Sep 2018 at 21:23, Dietmar Eggemann wrote:
>
> On 09/27/2018 03:19 AM, Wanpeng Li wrote:
> > On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann
> > wrote:
> >>
> >> Hi,
> >>
> >> On 09/26/2018 11:50 AM, Wanpeng Li wrote:
> >>> Hi Dietmar,
> >>> On Tue, 28 Aug 2018 at 22:55, Dietmar Eggema
On 09/27/2018 03:19 AM, Wanpeng Li wrote:
On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann wrote:
Hi,
On 09/26/2018 11:50 AM, Wanpeng Li wrote:
Hi Dietmar,
On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann wrote:
On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
On Fri, Aug 24, 2018 at 02:24:48PM
On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann wrote:
>
> Hi,
>
> On 09/26/2018 11:50 AM, Wanpeng Li wrote:
> > Hi Dietmar,
> > On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann
> > wrote:
> >>
> >> On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
> >>> On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve
Hi,
On 09/26/2018 11:50 AM, Wanpeng Li wrote:
> Hi Dietmar,
> On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann
> wrote:
>>
>> On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
>>> On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
>>> O
Hi Dietmar,
On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann wrote:
>
> On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
> > On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
> >> On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
> > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> >>>
> >
On 09/07/2018 12:58 AM, Vincent Guittot wrote:
On Fri, 7 Sep 2018 at 09:16, Juri Lelli wrote:
On 06/09/18 16:25, Dietmar Eggemann wrote:
Hi Juri,
On 08/23/2018 11:54 PM, Juri Lelli wrote:
On 23/08/18 18:52, Dietmar Eggemann wrote:
Hi,
On 08/21/2018 01:54 AM, Miguel de Dios wrote:
On 08/1
On Fri, 7 Sep 2018 at 09:16, Juri Lelli wrote:
>
> On 06/09/18 16:25, Dietmar Eggemann wrote:
> > Hi Juri,
> >
> > On 08/23/2018 11:54 PM, Juri Lelli wrote:
> > > On 23/08/18 18:52, Dietmar Eggemann wrote:
> > > > Hi,
> > > >
> > > > On 08/21/2018 01:54 AM, Miguel de Dios wrote:
> > > > > On 08/17
On 06/09/18 16:25, Dietmar Eggemann wrote:
> Hi Juri,
>
> On 08/23/2018 11:54 PM, Juri Lelli wrote:
> > On 23/08/18 18:52, Dietmar Eggemann wrote:
> > > Hi,
> > >
> > > On 08/21/2018 01:54 AM, Miguel de Dios wrote:
> > > > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> > > > > From: John Dias
>
Hi Juri,
On 08/23/2018 11:54 PM, Juri Lelli wrote:
On 23/08/18 18:52, Dietmar Eggemann wrote:
Hi,
On 08/21/2018 01:54 AM, Miguel de Dios wrote:
On 08/17/2018 11:27 AM, Steve Muckle wrote:
From: John Dias
[...]
I tried to catch this issue on my Arm64 Juno board using pi_test (and a
slig
On 08/29/2018 08:33 AM, Dietmar Eggemann wrote:
Yes, this solves the issue for the case I described. Using
'p->sched_remote_wakeup' (WF_MIGRATED) looks more elegant than using
'p->sched_class == &fair_sched_class'.
It's confirmed that this patch solves the original issue we saw (and my
test ca
On 08/29/2018 12:59 PM, Peter Zijlstra wrote:
On Wed, Aug 29, 2018 at 11:54:58AM +0100, Dietmar Eggemann wrote:
I forgot to mention that since fair_task's cpu affinity is restricted to
CPU4, there is no call to set_task_cpu()->migrate_task_rq_fair() since if
(task_cpu(p) != cpu) fails.
I think
On Wed, Aug 29, 2018 at 11:54:58AM +0100, Dietmar Eggemann wrote:
> I forgot to mention that since fair_task's cpu affinity is restricted to
> CPU4, there is no call to set_task_cpu()->migrate_task_rq_fair() since if
> (task_cpu(p) != cpu) fails.
>
> I think the combination of cpu affinity of the f
On 08/28/2018 03:53 PM, Dietmar Eggemann wrote:
On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
On 08/17/2018 11:27 AM, Steve Muckle wrote:
When rt_mutex_setprio changes a task's schedu
On 08/27/2018 12:14 PM, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
>> On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
> On 08/17/2018 11:27 AM, Steve Muckle wrote:
>>>
>> When rt_mutex_setprio changes a task's scheduling class to RT,
>> we're see
On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
> On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
> > > > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> >
> > > > > When rt_mutex_setprio changes a task's scheduling class to RT,
> > > > > we're seeing cases where the task's vruntime is n
On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
On 08/17/2018 11:27 AM, Steve Muckle wrote:
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being
On 08/23/2018 11:54 PM, Juri Lelli wrote:
I tried to catch this issue on my Arm64 Juno board using pi_test (and a
slightly adapted pip_test (usleep_val = 1500 and keep low as cfs)) from
rt-tests but wasn't able to do so.
# pi_stress --inversions=1 --duration=1 --groups=1 --sched id=low,policy=cf
> > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> > > When rt_mutex_setprio changes a task's scheduling class to RT,
> > > we're seeing cases where the task's vruntime is not updated
> > > correctly upon return to the fair class.
> > > Specifically, the following is being observed:
> > > - task i
On Mon, Aug 20, 2018 at 04:54:25PM -0700, Miguel de Dios wrote:
> On 08/17/2018 11:27 AM, Steve Muckle wrote:
> > From: John Dias
> >
> > When rt_mutex_setprio changes a task's scheduling class to RT,
> > we're seeing cases where the task's vruntime is not updated
> > correctly upon return to the
On 23/08/18 18:52, Dietmar Eggemann wrote:
> Hi,
>
> On 08/21/2018 01:54 AM, Miguel de Dios wrote:
> > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> > > From: John Dias
> > >
> > > When rt_mutex_setprio changes a task's scheduling class to RT,
> > > we're seeing cases where the task's vruntime i
Hi,
On 08/21/2018 01:54 AM, Miguel de Dios wrote:
On 08/17/2018 11:27 AM, Steve Muckle wrote:
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the f
On 08/17/2018 11:27 AM, Steve Muckle wrote:
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated wh
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted
29 matches
Mail list logo