From: Dinakar Guniguntala <dino@in.ibm.com>
To: Matthew Dobson <colpatch@us.ibm.com>
Cc: Paul Jackson <pj@sgi.com>, Simon Derr <Simon.Derr@bull.net>,
Nick Piggin <nickpiggin@yahoo.com.au>,
lkml <linux-kernel@vger.kernel.org>,
lse-tech <lse-tech@lists.sourceforge.net>,
Dipankar Sarma <dipankar@in.ibm.com>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC PATCH] Dynamic sched domains (v0.5)
Date: Thu, 5 May 2005 18:56:55 +0530 [thread overview]
Message-ID: <20050505132655.GA4028@in.ibm.com> (raw)
In-Reply-To: <4277F52B.8040908@us.ibm.com>
On Tue, May 03, 2005 at 03:03:23PM -0700, Matthew Dobson wrote:
> An interesting feature. I tried a while ago to get cpusets and
> sched_domains to play nice (nicer?) and didn't have much luck. It seems
> you're taking a better approach, with smaller patches. Good luck!
Thanks ! I would very much like to know your findings as far as
memory/node domains are concerned or are you going to be working on it?
I dont have any thoughts on it right now
> > -#ifdef CONFIG_HOTPLUG
> > +#if defined(CONFIG_HOTPLUG) || defined(CONFIG_CPUSETS)
> > #define __devinit
> > #define __devinitdata
> > #define __devexit
>
> This looks just plain wrong. Why do you need this? It doesn't seem that
> arch_init_sched_domains() and/or update_sched_domains() are called from
> anywhere that is cpuset related, so why the #ifdef CONFIG_CPUSETS?
cpu_attach_domain is defined as a __devinit, maybe I need to remove that
instead of the #ifdef
> > #ifdef CONFIG_SMP
> > -#define SCHED_DOMAIN_DEBUG
> > +#undef SCHED_DOMAIN_DEBUG
> > #ifdef SCHED_DOMAIN_DEBUG
> > static void sched_domain_debug(struct sched_domain *sd, int cpu)
> > {
>
> Is this just to quiet boot for your testing? Is there are better reason
> you're turning this off? It seems unrelated to the rest of your patch.
>
This gets called from cpu_attach_domain, and so everytime partitioning is done
and not only during boot with my changes
Thanks for your review !
-Dinakar
prev parent reply other threads:[~2005-05-05 13:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-01 19:09 [RFC PATCH] Dynamic sched domains (v0.5) Dinakar Guniguntala
2005-05-02 9:10 ` Nick Piggin
2005-05-02 17:17 ` Dinakar Guniguntala
2005-05-02 9:44 ` Nick Piggin
2005-05-02 17:16 ` Dinakar Guniguntala
2005-05-02 23:23 ` Nick Piggin
2005-05-03 14:58 ` Dinakar Guniguntala
2005-05-03 15:31 ` Paul Jackson
2005-05-02 18:01 ` Paul Jackson
2005-05-03 14:44 ` Dinakar Guniguntala
2005-05-03 15:21 ` Paul Jackson
2005-05-03 15:24 ` Paul Jackson
2005-05-03 22:03 ` Matthew Dobson
2005-05-04 0:08 ` Nick Piggin
2005-05-04 0:28 ` Matthew Dobson
2005-05-05 13:28 ` Dinakar Guniguntala
2005-05-05 13:26 ` Dinakar Guniguntala [this message]
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=20050505132655.GA4028@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox