lkml.org 
[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git pull] cpus4096 fixes
    Rusty Russell wrote:
    > On Monday 28 July 2008 18:16:39 Ingo Molnar wrote:
    >> * Rusty Russell <rusty@rustcorp.com.au> wrote:
    >>> Mike: I now think the right long-term answer is Linus' dense cpumap
    >>> idea + a convenience allocator for cpumasks. We sweep the kernel for
    >>> all on-stack vars and replace them with one or the other. Thoughts?
    >> The dense cpumap for constant cpumasks is OK as it's clever, compact and
    >> static.
    >>
    >> All-dynamic allocator for on-stack cpumasks ... is a less obvious
    >> choice.
    >
    > Sorry, I was unclear. "long-term" == "more than 4096 CPUs", since I thought
    > that was Mike's aim. If we only want to hack up 4k CPUS and stop, then I
    > understand the current approach.
    >
    > If we want huge cpu numbers, I think cpumask_alloc/free gives the clearest
    > code. So our approach is backwards: let's do that *then* put ugly hacks in
    > if it's really too slow.
    >
    > Cheers,
    > Rusty.

    Well, yes, "long-term" is not really that long and the system will be capable
    of supporting 16k cpus. With the limit on clock scalability, core count is
    going through the roof. Fortunately, we have a whole new release cycle to
    rethink some basic ideas.

    I did bring up a number of suggestions on how to replace cpumask_t, but they
    all seemed to hamper small systems in one way or another. And the goal, again
    was to minimize impact for 99.99% of the systems that won't have a thousand
    or more cpus. (Though it only takes 8 Larrabee chips to attain that.)

    Thanks,
    Mike


    \
     
     \ /
      Last update: 2008-07-28 20:27    [W:0.026 / U:151.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site