Re: [PATCH] cpuset: Rework sched domains and CPU hotplug handling(2.6.27-rc1)

From: Max Krasnyansky
Date: Wed Aug 06 2008 - 16:22:09 EST


Paul Jackson wrote:
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/