lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Jul 2014 17:05:38 +0200 From: Vlastimil Babka <vbabka@...e.cz> To: Joonsoo Kim <js1304@...il.com> CC: Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, David Rientjes <rientjes@...gle.com>, LKML <linux-kernel@...r.kernel.org>, linux-mm@...r.kernel.org, Minchan Kim <minchan@...nel.org>, Michal Nazarewicz <mina86@...a86.com>, Naoya Horiguchi <n-horiguchi@...jp.nec.com>, Christoph Lameter <cl@...ux.com>, Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>, Zhang Yanfei <zhangyanfei@...fujitsu.com> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists