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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
