[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ZONE_PADDING wastes 4 bytes of the new cacheline
    On Fri, Oct 22, 2004 at 01:02:24PM +1000, Nick Piggin wrote:
    > I don't agree, there are times when you need to know the bare pages_xxx
    > watermark, and times when you need to know the whole ->protection thing.

    we'll see, I agree current alloc_pages is quite clean but I'm quite
    tempted to have a strightforward alloc_pages as clean as 2.4:

    for (;;) {
    zone_t *z = *(zone++);
    if (!z)

    if (zone_free_pages(z, order) > z->watermarks[class_idx].low) {
    page = rmqueue(z, order);
    if (page)
    return page;

    2.6 is like this:

    /* Go through the zonelist once, looking for a zone with enough * free */
    for (i = 0; (z = zones[i]) != NULL; i++) {
    min = z->pages_low + (1<<order) + z->protection[alloc_type];

    if (z->free_pages < min)

    page = buffered_rmqueue(z, order, gfp_mask);
    if (page)
    goto got_pg;

    I don't see any benefit in limiting the high order, infact it seems a
    bad bug. If something you should limit the _small_ order, so that the
    high order will have a slight chance to succeed. You're basically doing
    the opposite.

    The pages_low is completely useless too for example and it could go.
    pages_min has some benefit for some more feature 2.6 provides (that
    could be translated in more watermarks, to separate the "settings of
    the watermarks" from the alloc_page user of the watermarks).

    > OK I dont disagree that your setup calculations are much nicer, and
    > the current ones are pretty broken...

    ok cool.
    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: 2005-03-22 14:07    [W:0.020 / U:17.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site