Re: [PATCH 3/5] Light Fragmentation Avoidance V20: 003_fragcore

[Mel Gorman]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/