![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2007-07-08 11:09 [from the cache] ©2003-2008 | |||||||||||||