From: Max Krasnyansky <maxk@qualcomm.com>
To: ego@in.ibm.com
Cc: Paul Menage <menage@google.com>,
Vegard Nossum <vegard.nossum@gmail.com>,
Paul Jackson <pj@sgi.com>,
a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [RFC][PATCH] CPUSets: Move most calls to rebuild_sched_domains() to the workqueue
Date: Thu, 26 Jun 2008 21:53:59 -0700 [thread overview]
Message-ID: <48647267.3030606@qualcomm.com> (raw)
In-Reply-To: <20080627032317.GB3419@in.ibm.com>
Gautham R Shenoy wrote:
> On Fri, Jun 27, 2008 at 08:52:28AM +0530, Gautham R Shenoy wrote:
>> On Thu, Jun 26, 2008 at 12:56:49AM -0700, Paul Menage wrote:
>>> CPUsets: Move most calls to rebuild_sched_domains() to the workqueue
>>>
>>> In the current cpusets code the lock nesting between cgroup_mutex and
>>> cpuhotplug.lock when calling rebuild_sched_domains is inconsistent -
>>> in the CPU hotplug path cpuhotplug.lock nests outside cgroup_mutex,
>>> and in all other paths that call rebuild_sched_domains() it nests
>>> inside.
>>>
>>> This patch makes most calls to rebuild_sched_domains() asynchronous
>>> via the workqueue, which removes the nesting of the two locks in that
>>> case. In the case of an actual hotplug event, cpuhotplug.lock nests
>>> outside cgroup_mutex as now.
>>>
>> Using a multithreaded workqueue(kevent here) for this is not such a
>> great idea this,since currently we cannot call
>> get_online_cpus() from a workitem executed by a multithreaded workqueue.
>>
>> Can one use a single threaded workqueue here instead ?
We could certainly do it in the single threaded workqueue. It won't help to
avoid circular locking dependencies though.
Did you get a chance to read entire thread on this topic ? There were some
questions that you might be able to answer.
Max
next prev parent reply other threads:[~2008-06-27 4:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 7:56 [RFC][PATCH] CPUSets: Move most calls to rebuild_sched_domains() to the workqueue Paul Menage
2008-06-26 9:34 ` Vegard Nossum
2008-06-26 9:50 ` Paul Menage
2008-06-26 18:49 ` Max Krasnyansky
2008-06-26 19:19 ` Peter Zijlstra
2008-06-26 20:34 ` Paul Menage
2008-06-26 21:17 ` Paul Menage
2008-06-27 5:10 ` Max Krasnyansky
2008-06-27 5:51 ` Paul Menage
2008-06-27 17:31 ` Max Krasnyansky
2008-06-27 3:22 ` Gautham R Shenoy
2008-06-27 3:23 ` Gautham R Shenoy
2008-06-27 4:53 ` Max Krasnyansky [this message]
2008-06-27 16:42 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48647267.3030606@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=oleg@tv-sign.ru \
--cc=pj@sgi.com \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.