Messages in this thread | | | Date | Wed, 16 Nov 2005 10:42:31 +0000 (GMT) | From | Mel Gorman <> | Subject | Re: [PATCH 3/5] Light Fragmentation Avoidance V20: 003_fragcore |
| |
On Wed, 16 Nov 2005, KAMEZAWA Hiroyuki wrote:
> > +/* Remove an element from the buddy allocator from the fallback list */ > > +static struct page *__rmqueue_fallback(struct zone *zone, int order, > > + int alloctype) > > Should we avoid this fallback as much as possible ?
Avoiding fallback as much as possible is something I would push into a zone approach that can be developer separetly to this. I want to give hard guarantees in special zones about fallbacks and best effort everywhere else with this. Taking complex steps to avoid tough fallbacks here hurts the general path on a typical machine.
> I think this is a weak point of this approach. > > > + /* > > + * If breaking a large block of pages, place the buddies > > + * on the preferred allocation list > > + */ > > + if (unlikely(current_order >= MAX_ORDER / 2)) { > > + alloctype = !alloctype; > > + change_pageblock_type(zone, page); > > + area = &zone->free_area_lists[alloctype][current_order]; > > + } > Changing RCLM_NORCLM to RLCM_EASY is okay ??
Yes. If anything, it's the other way around one would be concerned about. The anti-defrag approach just groups related allocations together as much as possible. If the grouping is not possible without taking expensive steps like balancing or reclaiming, it tries to steal the largest possible block from the other list to reduce the chances that fallbacks will occur in the near future.
> If so, I think adding similar code to free_pages_bulk() is better. >
It's at allocation time if you know whether fallbacks are needed or not. To do something similar at free, you are entering the realm of watermarks, balances and tunables. As it is, the usemap tells __free_pages_bulk() what free list pages should be going back to.
-- 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/
| |