From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>, 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 18:26:47 -0500 [thread overview]
Message-ID: <52E2F6B7.3050304@redhat.com> (raw)
In-Reply-To: <20140124225156.GG4407@cmpxchg.org>
On 01/24/2014 05:51 PM, Johannes Weiner wrote:
> On Fri, Jan 24, 2014 at 02:30:03PM -0800, Andrew Morton wrote:
>> On Fri, 24 Jan 2014 17:03:02 -0500 Johannes Weiner <hannes@cmpxchg.org> wrote:
>>
>>> Tejun reported stuttering and latency spikes on a system where random
>>> tasks would enter direct reclaim and get stuck on dirty pages. Around
>>> 50% of memory was occupied by tmpfs backed by an SSD, and another disk
>>> (rotating) was reading and writing at max speed to shrink a partition.
>>
>> Do you think this is serious enough to squeeze these into 3.14?
>
> We have been biasing towards cache reclaim at least as far back as the
> LRU split and we always considered anon dirtyable, so it's not really
> a *new* problem. And there is a chance of regressing write bandwidth
> for certain workloads by effectively shrinking their dirty limit -
> although that is easily fixed by changing dirty_ratio.
>
> On the other hand, the stuttering is pretty nasty (could reproduce it
> locally too) and the workload is not exactly esoteric. Plus, I'm not
> sure if waiting will increase the test exposure.
>
> So 3.14 would work for me, unless Mel and Rik have concerns.
3.14 would be fine, indeed.
On the other hand, if there are enough user reports of the stuttering
problem on older kernels, a -stable backport could be appropriate
too...
--
All rights reversed
--
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>
prev parent reply other threads:[~2014-01-24 23:26 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 ` [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache Tejun Heo
2014-01-24 23:31 ` Tejun Heo
2014-01-24 22:30 ` Andrew Morton
2014-01-24 22:51 ` Johannes Weiner
2014-01-24 23:26 ` Rik van Riel [this message]
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=52E2F6B7.3050304@redhat.com \
--to=riel@redhat.com \
--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=tj@kernel.org \
/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).