Re: [PATCH 3/7] Fragmentation Avoidance V16: 003_fragcore

Mel Gorman
2005-10-05T17:45:59Z

On Wed, 5 Oct 2005, Dave Hansen wrote:

> On Wed, 2005-10-05 at 18:14 +0100, Mel Gorman wrote:
> > On Wed, 5 Oct 2005, Dave Hansen wrote:
> > > On Wed, 2005-10-05 at 15:46 +0100, Mel Gorman wrote:
> > > >
> > > > @@ -1483,8 +1540,10 @@ void show_free_areas(void)
> > > >
> > > > spin_lock_irqsave(&zone->lock, flags);
> > > > for (order = 0; order < MAX_ORDER; order++) {
> > > > - nr = zone->free_area[order].nr_free;
> > > > - total += nr << order;
> > > > + for (type=0; type < RCLM_TYPES; type++) {
> > > > + nr = zone->free_area_lists[type][order].nr_free;
> > > > + total += nr << order;
> > > > + }
> > >
> > > Can that use the new for_each_ macro?
> >
> > Now I remember why, it's because of the printf below "for (type=0" . The
> > printf has to happen once for each order. With the for_each_macro, it
> > would happen for each type *and* order.
>
> Actually, that's for debugging, so we might want to do that anyway. Can
> you put it in a separate patch and explain?
>

To print out for each type and order, I'll need the type_names[] array
from 007_stats but I don't see it as a problem.

The problem is that by putting all the changes to this function in another
patch, the kernel will not build after applying 003_fragcore. I am
assuming that is bad. I think it makes sense to leave this patch as it is,
but have a 004_showfree patch that adds the type_names[] array and a more
detailed printout in show_free_areas. The remaining patches get bumped up
a number.

Would you be happy with that?

--
Mel Gorman
Part-time Phd Student Java Applications Developer
University of Limerick IBM Dublin Software Lab