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: Mon, 18 Jul 2016 13:34:29 +0200 From: Vlastimil Babka <vbabka@...e.cz> To: Michal Hocko <mhocko@...nel.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...hsingularity.net>, Joonsoo Kim <iamjoonsoo.kim@....com>, David Rientjes <rientjes@...gle.com>, Rik van Riel <riel@...hat.com> Subject: Re: [PATCH 3/8] mm, page_alloc: don't retry initial attempt in slowpath On 07/18/2016 01:29 PM, Michal Hocko wrote: > On Mon 18-07-16 13:22:57, Vlastimil Babka wrote: >> After __alloc_pages_slowpath() sets up new alloc_flags and wakes up kswapd, it >> first tries get_page_from_freelist() with the new alloc_flags, as it may >> succeed e.g. due to using min watermark instead of low watermark. It makes >> sense to to do this attempt before adjusting zonelist based on >> alloc_flags/gfp_mask, as it's still relatively a fast path if we just wake up >> kswapd and successfully allocate. >> >> This patch therefore moves the initial attempt above the retry label and >> reorganizes a bit the part below the retry label. We still have to attempt >> get_page_from_freelist() on each retry, as some allocations cannot do that >> as part of direct reclaim or compaction, and yet are not allowed to fail >> (even though they do a WARN_ON_ONCE() and thus should not exist). We can reuse >> the call meant for ALLOC_NO_WATERMARKS attempt and just set alloc_flags to >> ALLOC_NO_WATERMARKS if the context allows it. As a side-effect, the attempts >> from direct reclaim/compaction will also no longer obey watermarks once this >> is set, but there's little harm in that. >> >> Kswapd wakeups are also done on each retry to be safe from potential races >> resulting in kswapd going to sleep while a process (that may not be able to >> reclaim by itself) is still looping. >> >> Signed-off-by: Vlastimil Babka <vbabka@...e.cz> > > Same here, my ack still holds > Acked-by: Michal Hocko <mhocko@...e.com> Sorry, forgot to add them before sending. Thanks for both!
Powered by blists - more mailing lists