Re: [RFC PATCH] sched_domains: Make SD_NODE_INIT per-arch

From: Matthew Dobson (colpatch_at_us.ibm.com)
Date: 09/30/04

  • Next message: Stephen C. Tweedie: "Re: [PATCH/RFC] Simplified Readahead"
    To: Andrew Morton <akpm@osdl.org>
    Date:	Thu, 30 Sep 2004 13:20:25 -0700
    
    

    On Thu, 2004-09-30 at 12:23, Andrew Morton wrote:
    > Matthew Dobson <colpatch@us.ibm.com> wrote:
    > >
    > > I would like to try to get this in before then, unless this will really
    > > make things difficult for you.
    >
    > It's about three weeks late for 2.6.9. I already have a string of CPU
    > scheduler patches awaiting the 2.6.10 stream and once we're at -rc2 we
    > really should only be looking at bugfixes.

    Yeah, that's entirely my fault for slacking on sending this out... I
    should have sent this a while ago. It is a small portion of some larger
    sched_domains changes that I am working on, but at some point I realized
    my larger changeset will be far more controversial and have a much
    larger impact than some of the smaller bits, as well as not being ready
    for prime time yet. Plus, like I said earlier, this allows
    arch-specific tweaking with minimal intrusiveness from the application
    of this patch forward.

    > Grumble, mutter.. it looks like one of those "if it compiled, it works"
    > things. Problem is, any time anyone touches that particular piece of the
    > kernel, half the architectures stop compiing.

    It *should* be. I'd be quite happy if you just picked it up in -mm to
    assure it far wider testing. I've compiled and booted it on x86, x86_64
    & ppc64. I've got no access to ia64 right now, or I'd test it there.
    But the patch *will* spit out #errors for any arch that doesn't have
    SD_NODE_INIT defined if they also have NUMA defined. I'm don't know of
    anyone else (ie: *not* x86, x86_64, ppc64 & ia64) that is building NUMA
    kernels, but if they are, it's a trivial patch to their
    include/asm/topology.h to make the arch build.

    Of course, the ultimate decision is yours, Andrew...

    -Matt

    -
    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: Stephen C. Tweedie: "Re: [PATCH/RFC] Simplified Readahead"

    Relevant Pages

    • Re: [DVB patch 21/51] ttusb-dec: kfree cleanup
      ... Andrew Morton wrote: ... > That's a bit strange - the code was OK beforehand. ... I just passed the patch on unchanged. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Next Month/Changes to where to send stuff
      ... Andrew Morton or for small stuff Rusty Russell's trivial patch ... being ignored by the mainstream (because 2.2 is ... I'm not sure what to do about the -ac patch. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: kgdb support in vanilla 2.6.2
      ... >>to splitting it into arch and generic bits. ... Coding style compliance, reduction of ifdefs, etc. Reduction of patch ... inbuilt assertion frameworks to various gdb stubs at various times. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] you have how many nodes??
      ... Ok, I made an attempt to clean up this mess quite a while ago, ... but that patch is utterly useless now. ... 04 - Fix up the arm arch. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH/RFC] Futex mmap_sem deadlock
      ... >> Below patch does so. ... having to add it to every arch. ... Above janitorial work could be done ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)