Paul Jackson wrote:
quoted text
> How about this ... two routines quite identical and parallel,
> even in their names, except that one is async and the other not:
> 
> ==================================================================
> 
> /*
>  * Rebuild scheduler domains, asynchronously in a separate thread.
>  *
>  * If the flag 'sched_load_balance' of any cpuset with non-empty
>  * 'cpus' changes, or if the 'cpus' allowed changes in any cpuset
>  * which has that flag enabled, or if any cpuset with a non-empty
>  * 'cpus' is removed, then call this routine to rebuild the
>  * scheduler's dynamic sched domains.
>  *
>  * The rebuild_sched_domains() and partition_sched_domains()
>  * routines must nest cgroup_lock() inside get_online_cpus(),
>  * but such cpuset changes as these must nest that locking the
>  * other way, holding cgroup_lock() for much of the code.
>  *
>  * So in order to avoid an ABBA deadlock, the cpuset code handling
>  * these user changes delegates the actual sched domain rebuilding
>  * to a separate workqueue thread, which ends up processing the
>  * above rebuild_sched_domains_thread() function.
>  */
> static void async_rebuild_sched_domains(void)
> {
>         queue_work(cpuset_wq, &rebuild_sched_domains_work);
> }
> 
> /*
>  * Accomplishes the same scheduler domain rebuild as the above
>  * async_rebuild_sched_domains(), however it directly calls the
>  * rebuild routine inline, rather than calling it via a separate
>  * asynchronous work thread.
>  *
>  * This can only be called from code that is not holding
>  * cgroup_mutex (not nested in a cgroup_lock() call.)
>  */
> void inline_rebuild_sched_domains(void)
> {
>         rebuild_sched_domains_thread(NULL);
> }
> 
> ==================================================================

Sure. That looks fine. Although inline_ will probably be a bit confusing 
since one may think that it has something to do with the C 'inline'.
I'd suggest either sync_rebuild_sched_domains() or simply 
rebuild_sched_domains(). The later has the advantage that the patch will 
not have to touch the scheduler code.

Let me know your preference and I'll respin the patch.

Max

--
unsubscribe notice
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/