linux-kernel - Re: [RFC 0/3] Recursive reclaim (on __PF

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: <Pine.LNX.4.64.0709101220001.24735@schroedinger.engr.sgi.com>
Date:	Mon, 10 Sep 2007 12:25:13 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Daniel Phillips <phillips@...nq.net>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, dkegel@...gle.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Miller <davem@...emloft.net>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

On Wed, 5 Sep 2007, Daniel Phillips wrote:

> > Na, that cannot be the case since it only activates when an OOM
> > condition would otherwise result.
> 
> I did not express myself clearly then.  Compared to our current 
> anti-deadlock patch set, you patch set is a regression.  Because 
> without help from some of our other patches, it does deadlock.  
> Obviously, we cannot have that.

Of course boundless allocations from interrupt / reclaim context will 
ultimately crash the system. To fix that you need to stop the networking 
layer from performing these.

> > Given your tests: It looks like we do not need it.
> 
> I do not agree with that line of thinking.  A single test load only 
> provides evidence, not proof.  Your approach is not obviously correct, 
> quite the contrary.  The tested patch set does not help atomic alloc at 
> all, which is clearly a problem we can hit, we just did not hit it this 
> time.

The patch is obviously correct because it provides memory where we used to 
fail.

> > We have a global dirty page limit already. I fully support Peters
> > work on dirty throttling.
> 
> Alas, I communicated exactly the opposite of what I intended.  We do not 
> like the global dirty limit.  It makes the vm complex and fragile, 
> unnecessarily.  We favor an approach that places less reliance on the 
> global dirty limit so that we can remove some of the fragile and hard 
> to support workarounds we have had to implement because of it.

So far our experience has just been the opposite and Peter's other patches 
demonstrate the same. Dirty limits make the VM stable and increase I/O 
performance.




-
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/