On Wed, Aug 10, 2016 at 11:12:23AM +0200, Vlastimil Babka wrote: > Compaction uses a watermark gap of (2UL << order) pages at various places and > it's not immediately obvious why. Abstract it through a compact_gap() wrapper > to create a single place with a thorough explanation. > > Signed-off-by: Vlastimil Babka <[email protected]> > Acked-by: Michal Hocko <[email protected]> > --- > include/linux/compaction.h | 16 ++++++++++++++++ > mm/compaction.c | 7 +++---- > mm/vmscan.c | 6 +++--- > 3 files changed, 22 insertions(+), 7 deletions(-) > > diff --git a/include/linux/compaction.h b/include/linux/compaction.h > index a1fba9994728..e7f0d34a90fe 100644 > --- a/include/linux/compaction.h > +++ b/include/linux/compaction.h > @@ -58,6 +58,22 @@ enum compact_result { > > struct alloc_context; /* in mm/internal.h */ > > +/* > + * Number of free order-0 pages that should be available above given > watermark > + * to make sure compaction has reasonable chance of not running out of free > + * pages that it needs to isolate as migration target during its work. > + */ > +static inline unsigned long compact_gap(unsigned int order) > +{ > + /* > + * Although all the isolations for migration are temporary, compaction > + * may have up to 1 << order pages on its list and then try to split > + * an (order - 1) free page. At that point, a gap of 1 << order might > + * not be enough, so it's safer to require twice that amount. > + */ > + return 2UL << order; > +}
I agree with this wrapper function but there is a question. Could you elaborate more on this code comment? Freescanner could keep COMPACT_CLUSTER_MAX freepages on the list. It's not associated with requested order at least for now. Why compact_gap is 2UL << order in this case? Thanks.
