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: <170fa0d20709072212m4563ce76sa83092640491e4f3@mail.gmail.com>
Date:	Sat, 8 Sep 2007 01:12:24 -0400
From:	"Mike Snitzer" <snitzer@...il.com>
To:	"Daniel Phillips" <phillips@...nq.net>
Cc:	"Christoph Lameter" <clameter@....com>, 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 9/5/07, Daniel Phillips <phillips@...nq.net> wrote:
> On Wednesday 05 September 2007 03:42, Christoph Lameter wrote:
> > On Wed, 5 Sep 2007, Daniel Phillips wrote:
> > > If we remove our anti-deadlock measures, including the
> > > ddsnap.vm.fixes (a roll-up of Peter's patch set) and the request
> > > throttling code in dm-ddsnap.c, and apply your patch set instead,
> > > we hit deadlock on the socket write path after a few hours
> > > (traceback tomorrow).  So your patch set by itself is a stability
> > > regression.
> >
> > 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.

Can you be specific about which changes to existing mainline code were
needed to make recursive reclaim "work" in your tests (albeit less
ideally than peterz's patchset in your view)?

Also, in a previous post you stated:

>   Just to recap, we have identified two essential ingredients in the
> recipe for writeout deadlock prevention:
>
>  1) Throttle block IO traffic to a bounded maximum memory use.
>
>  2) Guarantee availability of the required amount of memory.

Which changes allowed you to address 1?  I had a look at the various
patches you provided (via svn) and it wasn't clear which subset
fulfilled 1 for you.  Does it work for all Block IO and not just
specially tuned drivers like ddsnap et al?

regards,
Mike
-
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/