Re: [PATCH v5 14/14] mm, compaction: try to capture the just-created high-order freepage
From: Vlastimil Babka
Date: Wed Jul 30 2014 - 11:05:47 EST
On 07/30/2014 04:19 PM, Joonsoo Kim wrote:
But, I guess that there is a reason that watermark_ok() is so
conservative. If page allocator aggressively provides high order page,
future atomic high order page request cannot succeed easily. For
preventing this situation, watermark_ok() should be conservative.
I don't think it's intentionally conservative, just unreliable. It tests two
things together:
1) are there enough free pages for the allocation wrt watermarks?
2) does it look like that there is a free page of the requested order?
I don't think that watermark_ok()'s intention is checking if there is a free
page of the requested order. If we want to know it, we could use more
easy way something like below.
X = number of total freepage - number of freepage lower than requested order
If X is positive, we can conclude that there is at least one freepage
of requested order and this equation is easy to compute.
I thought that's basically what it does, but...
But, watermark_ok() doesn't do that. Instead, it uses mark value to determine
if we can go further. I guess that this means that allocation/reclaim logic want
to preserve certain level of high order freepages according to system memory
size, although I don't know what the reason is exactly. So
the "aggressiveness" on capture logic here could break what
allocation/reclaim want.
Hm I see your point. So OK, I will check if the order=0 makes the
difference for page capture or not.
Thanks.
--
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/