linux-kernel - Re: [PATCH v5 14/14] mm, compaction: try to capture the just-created high-order freepage

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53D909C2.2010300@suse.cz>
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/