[lkml]   [2007]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] change global zonelist order v4 [0/2]
    On Thu, 2007-05-03 at 22:47 -0700, Andrew Morton wrote:
    > On Fri, 27 Apr 2007 14:45:30 +0900 KAMEZAWA Hiroyuki <> wrote:
    > > Hi, this is version 4. including Lee Schermerhon's good rework.
    > > and automatic configuration at boot time.
    > hm, this adds rather a lot of code. Have we established that it's worth
    > it?

    See below. Something is needed here on some platforms. The current
    zonelist ordering results in some unfortunate behavior on some

    > And it's complex - how do poor users know what to do with this new control?
    Kame's autoconfig seems to be doing the right thing for our platform.
    Might not be the case for other platforms, or some workloads on them. I
    suppose the documentation in sysctl.txt could be expanded to describe
    when you might want to select a non-default setting, should we decide to
    provide that capability.

    > This:
    > + * = "[dD]efault | "0" - default, automatic configuration.
    > + * = "[nN]ode"|"1" - order by node locality,
    > + * then zone within node.
    > + * = "[zZ]one"|"2" - order by zone, then by locality within zone
    > seems a bit excessive. I think just the 0/1/2 plus documentation would
    > suffice?

    I agree, but I was considering dropping the "0/1/2" in favor of the more
    descriptive [IMO] values ;-).

    > I haven't followed this discussion very closely I'm afraid. If we came up
    > with a good reason why Linux needs this feature then could someone please
    > (re)describe it?

    Kame originally described the need for it in:

    I chimed in with support as we have a similar need for our cell-based
    ia64 platforms:

    I can easily consume all of DMA on our platforms [configured as 100%
    "cell local memory" -- always leaves some "cache-line interleaved" at
    phys addr zero => ZONE_DMA] by allocating, e.g., a shared memory segment
    of size > 1 node's memory + size of ZONE_DMA. This occurs because the
    node containing zone DMA is always 2nd in a zone's ZONE_NORMAL zonelist
    [after the zone itself, assuming it has memory]. Then, any driver that
    requests memory from ZONE_DMA will be denied, resulting in IO errors,
    death of hald [maybe that's a feature? ;-)], ...

    I guess I would be happy with Kame's V3 patch that unconditionally
    changes the order to be zone first--i.e., ZONE_NORMAL for all nodes
    before ZONE_DMA*:

    However, this patch apparently crossed in the mail with Christoph's
    observation that making the new order [zone order] the default w/o any
    option wouldn't be appropriate for some configurations:

    Meanwhile, I was factoring out common code in Kame's V1/V2 patch and
    adding the "excessive" user interface to the boot parameter/sysctl.
    After some additional rework, Kame posted this a V4--the one you're

    If we decide to proceed with this, I have another "cleanup" patch that
    eliminates some redundant "estimating of zone order" [autoconfig] and
    reports what order was chosen in the "Build %d zonelists..." message.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-04 19:15    [W:0.025 / U:10.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site