Re: [RFC] Thread Migration Preemption

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 2007-07-06 at 16:12 +1000, Nick Piggin wrote:
> Mathieu Desnoyers wrote:

> > migration_disable();
> > local_inc(&__get_cpu_var(&my_local_t_var));
> > migration_enable();
> > 

[...]

> This seems like way too much stuff to add just for this type of thing. Why
> not just disable and reenable preempt? Surely local_inc is not going to take
> so long that disabling preemption matters.

For this given example, it may be too much fine tuning. But there are
other things (at least in RT) where this would be very helpful. One
thing is that in RT an IRQ thread might service a softirq if that
softirq thread is of the same priority as the IRQ thread. The difference
between an IRQ thread and a softirq thread is that the IRQ thread may
migrate but the softirq thread may not. So to do this performance
enhancement, we need to temporarily pin the IRQ thread to the CPU, which
is expensive (set_cpus_allowed).  This would make it much simpler and
light weight to implement.

> 
> The task struct is not something we should just be carefree putting crap
> into because it is seemingly free :(
> 

Agreed, but as the subject says "RFC".  Perhaps we can make it a bit
more complex and put this as one of the most significant bits in the
preempt_count. We would just need to mask off that bit in all the archs
when determining if we should preempt or not.  That's more complex, but
keeps the task struct free from more luggage.

-- Steve