From: Tejun Heo <tj@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache
Date: Fri, 24 Jan 2014 17:21:44 -0500 [thread overview]
Message-ID: <20140124222144.GA3197@htj.dyndns.org> (raw)
In-Reply-To: <1390600984-13925-1-git-send-email-hannes@cmpxchg.org>
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@kernel.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-01-24 22:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 22:03 [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache Johannes Weiner
2014-01-24 22:03 ` [patch 1/2] mm: page-writeback: fix dirty_balance_reserve subtraction from dirtyable memory Johannes Weiner
2014-01-24 23:05 ` Rik van Riel
2014-01-28 13:48 ` Michal Hocko
2014-01-24 22:03 ` [patch 2/2] mm: page-writeback: do not count anon pages as " Johannes Weiner
2014-01-24 23:25 ` Rik van Riel
2014-01-28 13:58 ` Michal Hocko
2014-01-24 22:21 ` Tejun Heo [this message]
2014-01-24 23:31 ` [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache Tejun Heo
2014-01-24 22:30 ` Andrew Morton
2014-01-24 22:51 ` Johannes Weiner
2014-01-24 23:26 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140124222144.GA3197@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).