On Mon, Jul 20, 2015 at 09:00:19AM +0100, Mel Gorman wrote: > From: Mel Gorman <mgorman@xxxxxxx> > > The primary purpose of watermarks is to ensure that reclaim can always > make forward progress in PF_MEMALLOC context (kswapd and direct reclaim). > These assume that order-0 allocations are all that is necessary for > forward progress. > > High-order watermarks serve a different purpose. Kswapd had no high-order > awareness before they were introduced (https://lkml.org/lkml/2004/9/5/9). > This was particularly important when there were high-order atomic requests. > The watermarks both gave kswapd awareness and made a reserve for those > atomic requests. > > There are two important side-effects of this. The most important is that > a non-atomic high-order request can fail even though free pages are available > and the order-0 watermarks are ok. The second is that high-order watermark > checks are expensive as the free list counts up to the requested order must > be examined. > > With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary to > have high-order watermarks. Kswapd and compaction still need high-order > awareness which is handled by checking that at least one suitable high-order > page is free. I totally agree removing watermark checking for order from PAGE_ALLOC_COSTLY_ORDER to MAX_ORDER. It doesn't make sense to maintain such high-order freepage that MM don't guarantee allocation success. For example, in my system, when there is 1 order-9 freepage, allocation request for order-9 fails because watermark check requires at least 2 order-9 freepages in order to succeed order-9 allocation. But, I think watermark checking with order up to PAGE_ALLOC_COSTLY_ORDER is different. If we maintain just 1 high-order freepages, successive high-order allocation request that should be success always fall into allocation slow-path and go into the direct reclaim/compaction. It enlarges many workload's latency. We should prepare at least some number of freepage to handle successive high-order allocation request gracefully. So, how about following? 1) kswapd checks watermark as is up to PAGE_ALLOC_COSTLY_ORDER. It guarantees kswapd prepares some number of high-order freepages so successive high-order allocation request will be handlded gracefully. 2) In case of !kswapd, just check whether appropriate freepage is in buddy or not. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>