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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <489A079E.5040903@qualcomm.com>
Date:	Wed, 06 Aug 2008 13:20:46 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Paul Jackson <pj@....com>
CC:	mingo@...e.hu, linux-kernel@...r.kernel.org, menage@...gle.com,
	a.p.zijlstra@...llo.nl, vegard.nossum@...il.com,
	lizf@...fujitsu.com
Subject: Re: [PATCH] cpuset: Rework sched domains and CPU hotplug handling
 (2.6.27-rc1)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/