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]
Date:	Sat, 31 Oct 2009 14:19:50 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pavel Machek <pavel@....cz>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>, stable@...nel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Frans Pop <elendil@...net.nl>, Jiri Kosina <jkosina@...e.cz>,
	Sven Geggus <lists@...hsschwanzdomain.de>,
	Karol Lewandowski <karol.k.lewandowski@...il.com>,
	Tobias Oetiker <tobi@...iker.ch>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Rik van Riel <riel@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Stephan von Krawczynski <skraw@...net.com>,
	kernel-testers@...r.kernel.org
Subject: Re: [PATCH 2/3] page allocator: Do not allow interrupts to use
 ALLOC_HARDER

On Sat, 31 Oct 2009, Pavel Machek wrote:

> > Um, no, it's a matter of the kernel implementation.  We allow such tasks 
> > to allocate deeper into reserves to avoid the page allocator from 
> > incurring a significant penalty when direct reclaim is required.  
> > Background reclaim has already commenced at this point in the
> > slowpath.
> 
> But we can't guarantee that enough memory will be ready in the
> reserves. So if realtime task relies on it, it is broken, and will
> fail to meet its deadlines from time to time.

This is truly a bizarre tangent to take, I don't quite understand the 
point you're trying to make.  Memory reserves exist to prevent blocking 
when we need memory the most (oom killed task or direct reclaim) and to 
allocate from when we can't (GFP_ATOMIC) or shouldn't (rt tasks) utilize 
direct reclaim.  The idea is to kick background reclaim first in the 
slowpath so we're only below the low watermark for a short period and 
allow the allocation to succeed.  If direct reclaim actually can't free 
any memory, the oom killer will free it for us.

So the realtime[*] tasks aren't relying on it at all, the ALLOC_HARDER 
exemption for them in the page allocator are a convenience to return 
memory faster than otherwise when the fastpath fails.  I don't see much 
point in arguing against that.

 [*] This is the current mainline definition of "realtime," which actually
     includes a large range of different priorities.  For strict realtime,
     you'd need to check out the -rt tree.
--
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