public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Gregory Haskins" <ghaskins@novell.com>
To: "Max Krasnyansky" <maxk@qualcomm.com>
Cc: <a.p.zijlstra@chello.nl>, <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	redoscheddomain managment (take 2)
Date: Thu, 17 Jul 2008 05:57:37 -0600	[thread overview]
Message-ID: <487EFB71.BA47.005A.0@novell.com> (raw)
In-Reply-To: <487EF1E9.2040101@qualcomm.com>

>>> On Thu, Jul 17, 2008 at  3:16 AM, in message <487EF1E9.2040101@qualcomm.com>,
Max Krasnyansky <maxk@qualcomm.com> wrote: 

> 
> Gregory Haskins wrote:
>> Well, admittedly I am not entirely clear on what problem is being solved as
>> I was not part of the original thread with Linus.  My impression of what you
>> were trying to solve was to eliminate the need to rebuild the domains for a
>> hotplug event (which I think is a good problem to solve), thus eliminating
>> some complexity and (iiuc) races there.
>> 
>> However, based on what you just said, I am not sure I've got that entirely
>> right anymore.  Can you clarify the intent (or point me at the original 
> thread)
>> so we are on the same page?
> Here is the link to the original thread
> 	http://lkml.org/lkml/2008/7/11/328
> And here is where Linus explained the idea
> 	http://lkml.org/lkml/2008/7/12/137
> 
> I'll reply to the rest of your email tomorrow (can't keep my yes open any
> longer :)).
> 
> Max

Hi Max,
  Thanks for the pointers.  I see that I did indeed misunderstand the intent of the patch.
It seems you already solved the rebuild problem, and were just trying to solve the
"migrate to a dead cpu" problem that Linus mentions as a solution with cpu_active_map.

In that case, note that rq->rd->online already fits the bill, I believe.  In a nutshell,
rq->rd->span contains all the cpus within your disjoint cpuset, and rq->rd->online,
contains the subset of rq->rd->span that are online.  The online bit is cleared at the
earliest point in cpu hotplug removal (DYING), and it is set at the very latest point on
insertion (ONLINE).  Therefore it is redundant with the cpus_active_map concept.

I think the simplest solution is to make sure that we cpus_and against rq->rd->online
before allowing a migration.  This is how I intended the mask to be used, anyway.  Its
what the RT scheduler does.  It sounds like we just need to touch up the few places
in the CFS side that were causing those oops.

Thoughts?

-Greg 


  reply	other threads:[~2008-07-17 11:53 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         ` Gregory Haskins [this message]
2008-07-17 18:52           ` [PATCH] cpu hotplug, sched: Introduce cpu_active_map and redoscheddomain " 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
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=487EFB71.BA47.005A.0@novell.com \
    --to=ghaskins@novell.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dmitry.adamushko@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox