From: Dinakar Guniguntala <dino@in.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Paul Jackson <pj@sgi.com>, Simon Derr <Simon.Derr@bull.net>,
lkml <linux-kernel@vger.kernel.org>,
lse-tech <lse-tech@lists.sourceforge.net>,
Matthew Dobson <colpatch@us.ibm.com>,
Dipankar Sarma <dipankar@in.ibm.com>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 2/3] Dynamic sched domains (v0.6)
Date: Tue, 17 May 2005 15:05:48 +0530 [thread overview]
Message-ID: <20050517093548.GA5068@in.ibm.com> (raw)
In-Reply-To: <42898E61.3060304@yahoo.com.au>
On Tue, May 17, 2005 at 04:25:37PM +1000, Nick Piggin wrote:
> >+
> >+ lock_cpu_hotplug();
> >+ partition_sched_domains(&pspan, &cspan);
> >+ unlock_cpu_hotplug();
> >+}
> >+
>
> I don't think the cpu hotplug lock isn't supposed to provide
> synchronisation between readers (for example, it may be turned
> into an rwsem), but only between the thread and the cpu hotplug
> callbacks.
That should be ok
>
> In that case, can you move this locking into kernel/sched.c, and
> add the comment in partition_sched_domains that the callers must
> take care of synchronisation (which without reading the code, I
> assume you're doing with the cpuset sem?).
I didnt want to do this as my next patch, which introduces
hotplug support for dynamic sched domains, also calls
partition_sched_domains. That code is called with the hotplug lock
already held. (I am still testing that code, it should be out by
this weekend)
However I will add a comment about the synchronization and yes
currently it is taken care of by the cpuset sem
-Dinakar
next prev parent reply other threads:[~2005-05-17 9:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-17 4:10 [RFT PATCH] Dynamic sched domains (v0.6) Dinakar Guniguntala
2005-05-17 4:12 ` [PATCH 2/3] " Dinakar Guniguntala
2005-05-17 6:25 ` Nick Piggin
2005-05-17 9:35 ` Dinakar Guniguntala [this message]
2005-05-17 4:14 ` [PATCH 3/3] " Dinakar Guniguntala
2005-05-18 5:53 ` [RFT PATCH] " Paul Jackson
2005-05-18 18:06 ` [Lse-tech] " Dinakar Guniguntala
2005-05-18 21:02 ` Paul Jackson
2005-05-18 21:04 ` Paul Jackson
2005-05-18 21:05 ` Paul Jackson
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=20050517093548.GA5068@in.ibm.com \
--to=dino@in.ibm.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.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.