Messages in this thread | | | Date | Fri, 25 Jun 2004 01:09:19 +0200 | From | Andrea Arcangeli <> | Subject | Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms |
| |
On Thu, Jun 24, 2004 at 03:11:30PM -0700, Andrew Morton wrote: > After setting lower_zone_protection to 10: > > Active:111515 inactive:65009 dirty:116 writeback:0 unstable:0 free:3290 slab:75489 mapped:52247 pagetables:446 > DMA free:4172kB min:16kB low:32kB high:48kB active:0kB inactive:0kB present:16384kB > protections[]: 8 5156 5860 > Normal free:8736kB min:936kB low:1872kB high:2808kB active:352780kB inactive:224972kB present:901120kB > protections[]: 0 468 1172 > HighMem free:252kB min:128kB low:256kB high:384kB active:93280kB inactive:35064kB present:130516kB > protections[]: 0 0 64 > > It's a bit complex, and perhaps the relative levels of the various > thresholds could be tightened up.
this is the algorithm I added to 2.4 to produce good protection levels (with lower_zone_reserve_ratio supposedly tunable at boot time):
static int lower_zone_reserve_ratio[MAX_NR_ZONES-1] = { 256, 32 };
zone->watermarks[j].min = mask; zone->watermarks[j].low = mask*2; zone->watermarks[j].high = mask*3; /* now set the watermarks of the lower zones in the "j" classzone */ for (idx = j-1; idx >= 0; idx--) { zone_t * lower_zone = pgdat->node_zones + idx; unsigned long lower_zone_reserve; if (!lower_zone->size) continue;
mask = lower_zone->watermarks[idx].min; lower_zone->watermarks[j].min = mask; lower_zone->watermarks[j].low = mask*2; lower_zone->watermarks[j].high = mask*3;
/* now the brainer part */ lower_zone_reserve = realsize / lower_zone_reserve_ratio[idx]; lower_zone->watermarks[j].min += lower_zone_reserve; lower_zone->watermarks[j].low += lower_zone_reserve; lower_zone->watermarks[j].high += lower_zone_reserve;
realsize += lower_zone->realsize; }
Your code must be inferior since it doesn't even allow to tune each zone differently (you seems not to have a lower_zone_reserve_ratio[idx]). Not sure why you dont' simply forward port the code from 2.4 instead of reinventing it. - 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/
| |