linux-kernel - Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks

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:	Thu, 23 Aug 2007 13:23:00 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrea Arcangeli <andrea@...e.de>
cc:	Rik van Riel <riel@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org,
	dkegel@...gle.com, akpm@...ux-foundation.org,
	Nick Piggin <npiggin@...e.de>, ak@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks

On Thu, 23 Aug 2007, Andrea Arcangeli wrote:

> On Tue, Aug 21, 2007 at 03:32:25PM -0700, Christoph Lameter wrote:
> > 1. Like in the earlier patchset allow reentry to reclaim under 
> >    PF_MEMALLOC if we are out of all memory.
> 
> Can you simply tweak on the may_writepage flag only to achieve the
> second pass? We're talking here about a totally non-performance case,
> almost impossible to hit in practice unless you do real weird things,
> and certainly very unlikely to happen. So I'm unsure what's all that
> complexity just to make a regular pass on the lru looking for clean
> pages, something may_writepage=0 already does.
> 

Yes that is what the PF_MEMALLOC patch that I posted before does. This 
discussion gets me more and more to thinking that the recursive reclaim on 
PF_MEMALLOC is all that is needed for emergency situations (to get out of 
the "tight spot").

See
http://marc.info/?l=linux-kernel&m=118710219116624&w=2

> If the PF_MEMALLOC is found empty, I agree entering reclaim a second
> time with may_writepage=0 sounds theoretically a good idea (in
> practice it should never be necessary). printk must also be printed to
> warn the user he was risking to deadlock for real and he has to
> increase the min_free_kbytes.

Ok. I can add a printk to that one.

> That sounds a bit risky, there are latency considerations here to
> make, GFP_ATOMIC will run with irq locally disabled and it may hang
> for indefinite amount of time (O(N)). So irq latency may break and it
> may be better to lose a packet once in a while than to hang
> interrupts. If you want to do this you'd probably need to add a new
> GFP_ATOMIC_RECLAIM or similar.

Well we could do the same as for PF_MEMALLOC: print a warning and then 
reclaim nevertheless if we cannot fail (We already have a GFP_NOFAIL 
flag). It is better to generate a latency than the system failing 
altogether. However the GFP_ATOMIC reclaim patchset is a 
bit more invasive (http://marc.info/?l=linux-mm&m=118710584014150&w=2). 
Maybe this is too much churn for the rare need of such a reclaim.
 
-
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/