On Thu, May 02, 2002 at 09:27:00PM +0200, Daniel Phillips wrote:
> On Thursday 02 May 2002 21:19, William Lee Irwin III wrote:
> > On Thu, May 02, 2002 at 08:41:36PM +0200, Andrea Arcangeli wrote:
> > > Dropping the loop when discontigmem is enabled is much more interesting
> > > optimization of course.
> > > Andrea
> >
> > Absolutely; I'd be very supportive of improvements for this case as well.
> > Many of the systems with the need for discontiguous memory support will
> > also benefit from parallelizations or other methods of avoiding references
> > to remote nodes/zones or iterations over all nodes/zones.
>
> Which loop in which function are we talking about?
the pgdat loops. example, this could be optimized for the 99% of userbase to:
do {
zonelist_t *zonelist = pgdat->node_zonelists + (GFP_USER & GFP_ZONEMASK);
zone_t **zonep = zonelist->zones;
zone_t *zone;
for (zone = *zonep++; zone; zone = *zonep++) {
unsigned long size = zone->size;
unsigned long high = zone->pages_high;
if (size > high)
sum += size - high;
}
#ifdef CONFIG_DISCONTIGMEM
pgdat = pgdat->node_next;
} while (pgdat);
#else
} while (0)
#endif
so allowing the compiler to remove a branch and a few instructions from
the asm, but it would be a microoptimization not visible in benchmarks,
I'm not actually suggesting that mostly for code clarity, branch
prediction should also take it right if it starts to be executed
frequently (hopefully the asm is large enough that it doesn't get
confused by the inner loop that is quite near).
Andrea
-
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/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:18 EST