On Mon, Nov 25, 2013 at 03:26:06PM +0100, Vlastimil Babka wrote: > Currently there are several functions to manipulate the deferred compaction > state variables. The remaining case where the variables are touched directly > is when a successful allocation occurs in direct compaction, or is expected > to be successful in the future by kswapd. Here, the lowest order that is > expected to fail is updated, and in the case of direct compaction, the > deferred > status is reset completely. > > Create a new function compaction_defer_reset() to encapsulate this > functionality and make it easier to understand the code. No functional change. > > Cc: Mel Gorman <[email protected]> > Cc: Rik van Riel <[email protected]> > Signed-off-by: Vlastimil Babka <[email protected]> > --- > include/linux/compaction.h | 12 ++++++++++++ > mm/compaction.c | 9 ++++----- > mm/page_alloc.c | 5 +---- > 3 files changed, 17 insertions(+), 9 deletions(-) > > diff --git a/include/linux/compaction.h b/include/linux/compaction.h > index 091d72e..da39978 100644 > --- a/include/linux/compaction.h > +++ b/include/linux/compaction.h > @@ -62,6 +62,18 @@ static inline bool compaction_deferred(struct zone *zone, > int order) > return zone->compact_considered < defer_limit; > } > > +/* Update defer tracking counters after successful allocation of given order > */ > +static inline void compaction_defer_reset(struct zone *zone, int order, > + bool reset_shift) > +{ > + if (reset_shift) { > + zone->compact_considered = 0; > + zone->compact_defer_shift = 0; > + } > + if (order >= zone->compact_order_failed) > + zone->compact_order_failed = order + 1; > +} > +
Nit pick The comment says this is called after a successful allocation but that is only true in one case. s/allocation/compaction/ ? reset_shift says what it does but not why and exposes an unnecessary. If this sees a second revision, maybe consider renaming it to something like alloc_success? With or without changes; Acked-by: Mel Gorman <[email protected]> -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
