Hi Peter,
On 09/05/14 15:51, James Hogan wrote:
> On 09/05/14 15:15, Peter Zijlstra wrote:
>> Most archs have (x86) hlt or (arm) wfi like idle instructions, and if
>> that is your only possible idle function, you'll require the interrupt
>> to wake up and there's really no point to having the POLL
On Fri, May 09, 2014 at 07:02:34PM +0200, Peter Zijlstra wrote:
> OK, so I'll queue a patch removing TIF_POLLING_NRFLAG for arm64.
---
Subject: arm64: Remove TIF_POLLING_NRFLAG
From: Peter Zijlstra
Date: Fri May 9 19:04:00 CEST 2014
The only idle method for arm64 is WFI and it therefore
uncond
On Fri, May 09, 2014 at 06:09:46PM +0100, Catalin Marinas wrote:
> On Fri, May 09, 2014 at 06:06:49PM +0100, Peter Zijlstra wrote:
> > Subject: arm64: Remove TIF_POLLING_NRFLAG
> > From: Peter Zijlstra
> > Date: Fri May 9 19:04:00 CEST 2014
> >
> > The only idle method for arm64 is WFI and it th
On Fri, May 09, 2014 at 06:06:49PM +0100, Peter Zijlstra wrote:
> Subject: arm64: Remove TIF_POLLING_NRFLAG
> From: Peter Zijlstra
> Date: Fri May 9 19:04:00 CEST 2014
>
> The only idle method for arm64 is WFI and it therefore
> unconditionally requires the reschedule interrupt when idle.
>
> S
On Fri, May 09, 2014 at 03:57:45PM +0100, Catalin Marinas wrote:
> On Fri, May 09, 2014 at 03:50:02PM +0100, Peter Zijlstra wrote:
> > On Fri, May 09, 2014 at 03:40:34PM +0100, Catalin Marinas wrote:
> >
> > > I wonder why we still need TIF_POLLING_NRFLAG for arm64. It was on arm
> > > until commi
On Fri, May 09, 2014 at 03:50:02PM +0100, Peter Zijlstra wrote:
> On Fri, May 09, 2014 at 03:40:34PM +0100, Catalin Marinas wrote:
>
> > I wonder why we still need TIF_POLLING_NRFLAG for arm64. It was on arm
> > until commit 16a8016372c42c7628eb (sanitize tsk_is_polling()). On arm64
> > we use wfi
On 09/05/14 15:15, Peter Zijlstra wrote:
> On Fri, May 09, 2014 at 02:37:27PM +0100, James Hogan wrote:
>> Hi Peter,
>>
>> On 11 April 2014 14:42, Peter Zijlstra wrote:
>>> + return !(fetch_or(&ti->flags, _TIF_NEED_RESCHED) &
>>> _TIF_POLLING_NRFLAG);
>>
>> This breaks the build on metag, a
On Fri, May 09, 2014 at 03:40:34PM +0100, Catalin Marinas wrote:
> I wonder why we still need TIF_POLLING_NRFLAG for arm64. It was on arm
> until commit 16a8016372c42c7628eb (sanitize tsk_is_polling()). On arm64
> we use wfi for idle or a firmware call but in both cases the assumption
> is that we
Hi Peter,
On Fri, May 09, 2014 at 03:15:20PM +0100, Peter Zijlstra wrote:
> On Fri, May 09, 2014 at 02:37:27PM +0100, James Hogan wrote:
> > On 11 April 2014 14:42, Peter Zijlstra wrote:
> > > + return !(fetch_or(&ti->flags, _TIF_NEED_RESCHED) &
> > > _TIF_POLLING_NRFLAG);
> >
> > This br
On Fri, May 09, 2014 at 02:37:27PM +0100, James Hogan wrote:
> Hi Peter,
>
> On 11 April 2014 14:42, Peter Zijlstra wrote:
> > + return !(fetch_or(&ti->flags, _TIF_NEED_RESCHED) &
> > _TIF_POLLING_NRFLAG);
>
> This breaks the build on metag, and I suspect arm64 too:
Yep, I just got a pat
Hi Peter,
On 11 April 2014 14:42, Peter Zijlstra wrote:
> Because mwait_idle_with_hints() gets called from !idle context it must
> call current_clr_polling(). This however means that resched_task() is
> very likely to send an IPI even when we were polling:
>
> CPU0
On Fri, 11 Apr 2014, Peter Zijlstra wrote:
> Because mwait_idle_with_hints() gets called from !idle context it must
> call current_clr_polling(). This however means that resched_task() is
> very likely to send an IPI even when we were polling:
>
> CPU0CPU
Because mwait_idle_with_hints() gets called from !idle context it must
call current_clr_polling(). This however means that resched_task() is
very likely to send an IPI even when we were polling:
CPU0 CPU1
if (current_set_polling_and_test())
goto out;
__
13 matches
Mail list logo
