From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Gregory Haskins <ghaskins@novell.com>
Cc: Max Krasnyansky <maxk@qualcomm.com>,
mingo@elte.hu, dmitry.adamushko@gmail.com,
torvalds@linux-foundation.org, pj@sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpu hotplug, sched:Introduce cpu_active_map and redoscheddomainmanagment (take 2)
Date: Tue, 22 Jul 2008 16:16:00 +0200 [thread overview]
Message-ID: <1216736160.7257.97.camel@twins> (raw)
In-Reply-To: <4885E952.8020708@novell.com>
On Tue, 2008-07-22 at 10:06 -0400, Gregory Haskins wrote:
> Max Krasnyansky wrote:
> > Greg, correct me if I'm wrong but we seem to have exact same issue with the
> > rq->rq->online map. Lets take "cpu going down" for example. We're clearing
> > rq->rd->online bit on DYING event, but nothing AFAICS prevents another cpu
> > calling rebuild_sched_domains()->partition_sched_domains() in the middle of
> > the hotplug sequence.
> > partition_sched_domains() will happily reset rd->rq->online mask and things
> > will fail. I'm talking about this path
> >
> > __build_sched_domains() -> cpu_attach_domain() -> rq_attach_root()
> > ...
> > cpu_set(rq->cpu, rd->span);
> > if (cpu_isset(rq->cpu, cpu_online_map))
> > set_rq_online(rq);
> > ...
> >
> >
>
> I think you are right, but wouldn't s/online/active above fix that as
> well? The active_map didnt exist at the time that code went in initially ;)
>
> > --
> >
> > btw Why didn't we convert sched*.c to use rq->rd->online when it was
> > introduced ? ie Instead of using cpu_online_map directly.
> >
> I think things were converted where they made sense to convert. But we
> also had a different goal at that time, so perhaps something was
> missed. If you think something else should be converted, please point
> it out.
>
> In the meantime, I would suggest we consider this patch on top of yours
> (applies to tip/sched/devel):
>
> ----------------------
>
> sched: Fully integrate cpus_active_map and root-domain code
>
> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Right, makes sense.
ACK
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 62b1b8e..99ba70d 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -6611,7 +6611,7 @@ static void rq_attach_root(struct rq *rq, struct
> root_domain *rd)
> rq->rd = rd;
>
> cpu_set(rq->cpu, rd->span);
> - if (cpu_isset(rq->cpu, cpu_online_map))
> + if (cpu_isset(rq->cpu, cpu_active_map))
> set_rq_online(rq);
>
> spin_unlock_irqrestore(&rq->lock, flags);
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index 7f70026..2bae8de 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -1004,7 +1004,7 @@ static void yield_task_fair(struct rq *rq)
> * search starts with cpus closest then further out as needed,
> * so we always favor a closer, idle cpu.
> * Domains may include CPUs that are not usable for migration,
> - * hence we need to mask them out (cpu_active_map)
> + * hence we need to mask them out (rq->rd->online)
> *
> * Returns the CPU we should wake onto.
> */
> @@ -1032,7 +1032,7 @@ static int wake_idle(int cpu, struct task_struct *p)
> || ((sd->flags & SD_WAKE_IDLE_FAR)
> && !task_hot(p, task_rq(p)->clock, sd))) {
> cpus_and(tmp, sd->span, p->cpus_allowed);
> - cpus_and(tmp, tmp, cpu_active_map);
> + cpus_and(tmp, tmp, task_rq(p)->rd->online);
> for_each_cpu_mask(i, tmp) {
> if (idle_cpu(i)) {
> if (i != task_cpu(p)) {
> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> index 24621ce..d93169d 100644
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -936,13 +936,6 @@ static int find_lowest_rq(struct task_struct *task)
> return -1; /* No targets found */
>
> /*
> - * Only consider CPUs that are usable for migration.
> - * I guess we might want to change cpupri_find() to ignore those
> - * in the first place.
> - */
> - cpus_and(*lowest_mask, *lowest_mask, cpu_active_map);
> -
> - /*
> * At this point we have built a mask of cpus representing the
> * lowest priority tasks in the system. Now we want to elect
> * the best one based on our affinity and topology.
>
> --------------
>
> Regards,
> -Greg
>
next prev parent reply other threads:[~2008-07-22 14:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 11:43 [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redo sched domain managment (take 2) Max Krasnyansky
2008-07-15 11:49 ` Marcel Holtmann
2008-07-15 11:52 ` Peter Zijlstra
2008-07-15 11:57 ` Marcel Holtmann
2008-07-15 12:03 ` Peter Zijlstra
2008-07-15 15:24 ` Linus Torvalds
2008-07-15 12:45 ` Gregory Haskins
2008-07-15 15:22 ` Linus Torvalds
2008-07-16 8:57 ` Dmitry Adamushko
2008-07-16 20:29 ` Max Krasnyansky
2008-07-16 21:55 ` Dmitry Adamushko
2008-07-16 12:12 ` Gregory Haskins
2008-07-16 21:44 ` Max Krasnyansky
2008-07-17 2:51 ` [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redosched " Gregory Haskins
2008-07-17 7:16 ` Max Krasnyansky
2008-07-17 11:57 ` [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redoscheddomain " Gregory Haskins
2008-07-17 18:52 ` Max Krasnyansky
2008-07-17 19:46 ` [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redoscheddomainmanagment " Gregory Haskins
2008-07-18 11:53 ` Peter Zijlstra
2008-07-18 12:22 ` [PATCH] cpu hotplug, sched:Introduce " Gregory Haskins
2008-07-22 5:10 ` Max Krasnyansky
2008-07-22 14:06 ` Gregory Haskins
2008-07-22 14:16 ` Peter Zijlstra [this message]
2008-07-22 14:17 ` Gregory Haskins
2008-07-22 14:26 ` Peter Zijlstra
2008-07-22 14:45 ` Gregory Haskins
2008-07-22 19:32 ` Max Krasnyansky
2008-08-11 13:11 ` Gregory Haskins
2008-08-11 21:57 ` Max Krasnyansky
2008-07-18 11:30 ` [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redo sched domain managment " Ingo Molnar
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=1216736160.7257.97.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=dmitry.adamushko@gmail.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=torvalds@linux-foundation.org \
/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.