Messages in this thread |  | | | Date | Wed, 5 Oct 2005 18:45:59 +0100 (IST) | | From | Mel Gorman <> | | Subject | Re: [PATCH 3/7] Fragmentation Avoidance V16: 003_fragcore |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |