(Oops, missed one that I should have forced to text/plain. Resending.)
On 5/18/2016 9:56 AM, Peter Zijlstra wrote:
On Tue, Apr 05, 2016 at 01:38:36PM -0400, Chris Metcalf wrote:+#ifdef CONFIG_TASK_ISOLATION +void task_isolation_debug(int cpu) +{ + struct task_struct *p; + + if (!task_isolation_possible(cpu)) + return; + + rcu_read_lock(); + p = cpu_curr(cpu); + get_task_struct(p); + rcu_read_unlock(); + task_isolation_debug_task(cpu, p); + put_task_struct(p);This is still broken...
I don't know how or why, though. :-) Can you give me a better idiom? This looks to my eye just like how it's done for something like sched_setaffinity() by one task on another task, and I would have assumed the risks there of the other task evaporating part way through would be the same as the risks here.
Also, I really don't like how you sprinkle a call all over the core kernel. At the very least make an inline fast path for this function to avoid the call whenever possible.
I can boost the "task_isolation_possible()" test up into a static inline, and only call in the case where we have a target cpu that is actually in the "task_isolation=" boot argument set. -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
