linux-kernel - Re: [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache

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: <20140124222144.GA3197@htj.dyndns.org>
Date:	Fri, 24 Jan 2014 17:21:44 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty
 cache

Hello,

On Fri, Jan 24, 2014 at 05:03:02PM -0500, Johannes Weiner wrote:
> These two patches fix the dirtyable memory calculation to acknowledge
> the fact that the VM does not really replace anon with dirty cache.
> As such, anon memory can no longer be considered "dirtyable."
> 
> Longer term we probably want to look into reducing some of the bias
> towards cache.  The problematic workload in particular was not even
> using any of the anon pages, one swap burst could have resolved it.

For both patches,

 Tested-by: Tejun Heo <tj@...nel.org>

I don't have much idea what's going on here, but the problem was
pretty ridiculous.  It's a 8gig machine w/ one ssd and 10k rpm
harddrive and I could reliably reproduce constant stuttering every
several seconds for as long as buffered IO was going on on the hard
drive either with tmpfs occupying somewhere above 4gig or a test
program which allocates about the same amount of anon memory.
Although swap usage was zero, turning off swap also made the problem
go away too.

The trigger conditions seem quite plausible - high anon memory usage
w/ heavy buffered IO and swap configured - and it's highly likely that
this is happening in the wild too.  (this can happen with copying
large files to usb sticks too, right?)

So, if this is the right fix && can be determined not to cause
noticeable regressions, it probably is worthwhile to cc -stable.

Thanks a lot!

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