Re: New NUMA scheduler and hotplug CPU

From: Nick Piggin (piggin_at_cyberone.com.au)
Date: 01/27/04

  • Next message: Eric: "Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED" 
    Date:	Tue, 27 Jan 2004 16:39:52 +1100
To: "Martin J. Bligh" <mbligh@aracnet.com>, Rusty Russell <rusty@rustcorp.com.au>

    Martin J. Bligh wrote:

    >>No, actually, it wouldn't. Take it from someone who has actually
    >>looked at the code with an eye to doing this.
    >>
    >>Replacing static structures by dynamic ones for an architecture which
    >>doesn't yet exist is NOT a good idea.
    >>
    >
    >Trying to force a dynamic infrastructure into the static bitmap arrays
    >that we have is the bad idea, IMHO. Why on earth would you want offline
    >CPUs in the scheduler domains? Just to make your coding easier? Sorry,
    >but that just doesn't cut it for me.
    >
    >
    >>Sure, if they were stupid they'd do it this way.
    >>
    >>If (when) an architecture has hotpluggable CPUs and NUMA
    >>characteristics, they probably will have fixed CPU *slots*, and number
    >>CPUs based on what slot they are in. Since the slots don't move, all
    >>your fancy dynamic logic will be wasted.
    >>
    >>When someone really has dynamic hotplug CPU capability with variable
    >>attributes, *they* can code up the dynamic hierarchy. Because *they*
    >>can actually test it!
    >>
    >
    >The cpu numbers are now dynamically allocated tags. I don't see why
    >we should sacrifice that just to get cpu hotplug. Sure, it makes your
    >coding a little harder, but ....
    >
    >
    >>>Yup ... but you don't have to enumerate all possible positions that way.
    >>>See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
    >>>Same thing applies.
    >>>
    >>Crap. When all the fixed per-cpu arrays have been removed from the
    >>kernel, come back and talk about instantiation and location of
    >>arbitrary CPUS.
    >>
    >>You're way overdesigning: have you been sharing food with the AIX guys?
    >>
    >
    >A cheap shot. Please, I'd expect better flaming from you.
    >
    >Sorry if this makes your coding harder, but it seems clear to me that
    >it's the right way to go. I guess the final decision is up to Andrew,
    >but I really don't want to see this kind of stuff. You don't start
    >kthreads for every possible cpu, do you?
    >
    >

    Well lets not worry too much about this for now. We could use
    static arrays and cpu_possible for now until we get a feel
    for what specific architectures want.

    To be honest I haven't seen the hotplug CPU code and I don't
    know about what architectures want to be doing with it, so
    this is my preferred direction just out of ignorance.

    An easy next step toward a dynamic scheme would be just to
    re-init the entire sched domain topology (the generic init uses
    the generic NUMA topology info which will have to be handled
    by these architectures anyway). Modulo a small locking problem.

    There aren't any fundamental design issues (with sched domains)
    that I can see preventing a more dynamic system so we can keep
    that in mind.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Eric: "Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED"

    Relevant Pages