Messages in this thread |  | | | Date | Fri, 22 Oct 2004 18:58:09 +0200 | | From | Andrea Arcangeli <> | | Subject | Re: 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) break; 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) continue; 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 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/
|  |