Messages in this thread |  | | Date | Fri, 14 Feb 2014 12:49:26 +0100 | From | Peter Zijlstra <> | Subject | Re: Another preempt folding issue? |
| |
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.
|  |