Messages in this thread | | | Subject | Re: [PATCH v6 08/11] mm, compaction: create compact_gap wrapper | From | Vlastimil Babka <> | Date | Tue, 16 Aug 2016 08:15:36 +0200 |
| |
On 08/16/2016 08:15 AM, Joonsoo Kim wrote: > On Wed, Aug 10, 2016 at 11:12:23AM +0200, Vlastimil Babka wrote: >> --- 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?
It's true that for high enough order, COMPACT_CLUSTER_MAX might be more limiting than 1 << order. But then it also helps to have more free pages for probability of compaction success, so I don't think it's worth complicating the compact_gap() formula.
> Thanks. >
| |