Messages in this thread | | | Date | Wed, 30 Jul 2014 17:05:38 +0200 | From | Vlastimil Babka <> | Subject | Re: [PATCH v5 14/14] mm, compaction: try to capture the just-created high-order freepage |
| |
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. >
| |