Re: Another preempt folding issue?

[Peter Zijlstra]

On Fri, Feb 14, 2014 at 12:24:42PM +0100, Stefan Bader wrote:
> Oh and one thing I was wondering. Not sure I do understand it right... When
> initially converting to percpu counts, you changed the 32bit assembly like that:
> 
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -362,12 +362,9 @@ END(ret_from_exception)
>  #ifdef CONFIG_PREEMPT
>  ENTRY(resume_kernel)
>         DISABLE_INTERRUPTS(CLBR_ANY)
> -       cmpl $0,TI_preempt_count(%ebp)  # non-zero preempt_count ?
> -       jnz restore_all
>  need_resched:
> -       movl TI_flags(%ebp), %ecx       # need_resched set ?
> -       testb $_TIF_NEED_RESCHED, %cl
> -       jz restore_all
> +       cmpl $0,PER_CPU_VAR(__preempt_count)
> +       jnz restore_all
>         testl $X86_EFLAGS_IF,PT_EFLAGS(%esp)    # interrupts off (exception path
>         jz restore_all
>         call preempt_schedule_irq
> 
> This seems to say if preempt_count was 0 then then if the thread flag was set
> and interrupts were not off(?) it would do a preempt ipi and then come back to
> re-check the thread flag.

No not an IPI; it would reschedule.

So the old code:

  if preempt_count != 0; continue out
  if !TIF_NEED_RESCHED; continue out
  if IRQs-off in calling context; continue out
  preempt_schedule_irq

The new code:

  if preempt_count != 0; continue out
  if IRQs-off in calling context; continue out
  preempt_schedule_irq

> This would now be if preempt_count is 0 only... and I wonder whether that would
> change from doing that loop...

We can do away with the TIF_NEED_RESCHED test because that state is
folded into the preempt_count by means of PREEMPT_NEED_RESCHED.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/