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

[Mel Gorman]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/