Messages in this thread | | | Date | Sun, 08 Jul 2007 19:05:45 +1000 | From | Nick Piggin <> | Subject | Re: [RFC] Thread Migration Preemption |
| |
Steven Rostedt wrote: > 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.
Well if this was just intended for -rt, then OK.
>>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.
Just so long as it stays out of mainline without a good reason that's fine.
-- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |