From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <jweiner@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>,
Minchan Kim <minchan.kim@gmail.com>,
Chris Mason <chris.mason@oracle.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
xfs@oss.sgi.com, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/4] mm: writeback: distribute write pages across allowable zones
Date: Tue, 20 Sep 2011 14:36:00 -0400 [thread overview]
Message-ID: <4E78DD10.4000900@redhat.com> (raw)
In-Reply-To: <1316526315-16801-3-git-send-email-jweiner@redhat.com>
On 09/20/2011 09:45 AM, Johannes Weiner wrote:
> This patch allows allocators to pass __GFP_WRITE when they know in
> advance that the allocated page will be written to and become dirty
> soon. The page allocator will then attempt to distribute those
> allocations across zones, such that no single zone will end up full of
> dirty, and thus more or less, unreclaimable pages.
>
> The global dirty limits are put in proportion to the respective zone's
> amount of dirtyable memory and allocations diverted to other zones
> when the limit is reached.
>
> For now, the problem remains for NUMA configurations where the zones
> allowed for allocation are in sum not big enough to trigger the global
> dirty limits, but a future approach to solve this can reuse the
> per-zone dirty limit infrastructure laid out in this patch to have
> dirty throttling and the flusher threads consider individual zones.
>
> Signed-off-by: Johannes Weiner<jweiner@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
The amount of work done in a __GFP_WRITE allocation looks
a little daunting, but doing that a million times probably
outweighs waiting on the disk even once, so...
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <jweiner@redhat.com>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, Andreas Dilger <adilger.kernel@dilger.ca>,
Mel Gorman <mgorman@suse.de>,
linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Wu Fengguang <fengguang.wu@intel.com>,
Chris Mason <chris.mason@oracle.com>,
Minchan Kim <minchan.kim@gmail.com>
Subject: Re: [patch 2/4] mm: writeback: distribute write pages across allowable zones
Date: Tue, 20 Sep 2011 14:36:00 -0400 [thread overview]
Message-ID: <4E78DD10.4000900@redhat.com> (raw)
In-Reply-To: <1316526315-16801-3-git-send-email-jweiner@redhat.com>
On 09/20/2011 09:45 AM, Johannes Weiner wrote:
> This patch allows allocators to pass __GFP_WRITE when they know in
> advance that the allocated page will be written to and become dirty
> soon. The page allocator will then attempt to distribute those
> allocations across zones, such that no single zone will end up full of
> dirty, and thus more or less, unreclaimable pages.
>
> The global dirty limits are put in proportion to the respective zone's
> amount of dirtyable memory and allocations diverted to other zones
> when the limit is reached.
>
> For now, the problem remains for NUMA configurations where the zones
> allowed for allocation are in sum not big enough to trigger the global
> dirty limits, but a future approach to solve this can reuse the
> per-zone dirty limit infrastructure laid out in this patch to have
> dirty throttling and the flusher threads consider individual zones.
>
> Signed-off-by: Johannes Weiner<jweiner@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
The amount of work done in a __GFP_WRITE allocation looks
a little daunting, but doing that a million times probably
outweighs waiting on the disk even once, so...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <jweiner@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>,
Minchan Kim <minchan.kim@gmail.com>,
Chris Mason <chris.mason@oracle.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
xfs@oss.sgi.com, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/4] mm: writeback: distribute write pages across allowable zones
Date: Tue, 20 Sep 2011 14:36:00 -0400 [thread overview]
Message-ID: <4E78DD10.4000900@redhat.com> (raw)
In-Reply-To: <1316526315-16801-3-git-send-email-jweiner@redhat.com>
On 09/20/2011 09:45 AM, Johannes Weiner wrote:
> This patch allows allocators to pass __GFP_WRITE when they know in
> advance that the allocated page will be written to and become dirty
> soon. The page allocator will then attempt to distribute those
> allocations across zones, such that no single zone will end up full of
> dirty, and thus more or less, unreclaimable pages.
>
> The global dirty limits are put in proportion to the respective zone's
> amount of dirtyable memory and allocations diverted to other zones
> when the limit is reached.
>
> For now, the problem remains for NUMA configurations where the zones
> allowed for allocation are in sum not big enough to trigger the global
> dirty limits, but a future approach to solve this can reuse the
> per-zone dirty limit infrastructure laid out in this patch to have
> dirty throttling and the flusher threads consider individual zones.
>
> Signed-off-by: Johannes Weiner<jweiner@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
The amount of work done in a __GFP_WRITE allocation looks
a little daunting, but doing that a million times probably
outweighs waiting on the disk even once, so...
next prev parent reply other threads:[~2011-09-20 18:36 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 13:45 [patch 0/4] 50% faster writing to your USB drive!* Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` [patch 1/4] mm: exclude reserved pages from dirtyable memory Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 15:21 ` Rik van Riel
2011-09-20 15:21 ` Rik van Riel
2011-09-20 15:21 ` Rik van Riel
2011-09-21 14:04 ` Mel Gorman
2011-09-21 14:04 ` Mel Gorman
2011-09-21 14:04 ` Mel Gorman
2011-09-21 15:03 ` Mel Gorman
2011-09-21 15:03 ` Mel Gorman
2011-09-21 15:03 ` Mel Gorman
2011-09-22 9:03 ` Johannes Weiner
2011-09-22 9:03 ` Johannes Weiner
2011-09-22 9:03 ` Johannes Weiner
2011-09-22 10:54 ` Mel Gorman
2011-09-22 10:54 ` Mel Gorman
2011-09-22 10:54 ` Mel Gorman
2011-09-23 14:38 ` [patch 1/4 v2] " Johannes Weiner
2011-09-23 14:38 ` Johannes Weiner
2011-09-23 14:38 ` Johannes Weiner
2011-09-28 4:55 ` Minchan Kim
2011-09-28 4:55 ` Minchan Kim
2011-09-28 4:55 ` Minchan Kim
2011-09-28 7:50 ` Johannes Weiner
2011-09-28 7:50 ` Johannes Weiner
2011-09-28 7:50 ` Johannes Weiner
2011-09-28 18:35 ` Minchan Kim
2011-09-28 18:35 ` Minchan Kim
2011-09-28 18:35 ` Minchan Kim
2011-09-20 13:45 ` [patch 2/4] mm: writeback: distribute write pages across allowable zones Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 18:36 ` Rik van Riel [this message]
2011-09-20 18:36 ` Rik van Riel
2011-09-20 18:36 ` Rik van Riel
2011-09-21 11:04 ` Shaohua Li
2011-09-21 11:04 ` Shaohua Li
2011-09-21 11:04 ` Shaohua Li
2011-09-21 13:35 ` Johannes Weiner
2011-09-21 13:35 ` Johannes Weiner
2011-09-21 13:35 ` Johannes Weiner
2011-09-21 14:30 ` Mel Gorman
2011-09-21 14:30 ` Mel Gorman
2011-09-21 14:30 ` Mel Gorman
2011-09-21 23:02 ` Andrew Morton
2011-09-21 23:02 ` Andrew Morton
2011-09-21 23:02 ` Andrew Morton
2011-09-22 8:52 ` Johannes Weiner
2011-09-22 8:52 ` Johannes Weiner
2011-09-22 8:52 ` Johannes Weiner
2011-09-23 14:41 ` [patch 1/2/4] mm: writeback: cleanups in preparation for per-zone dirty limits Johannes Weiner
2011-09-23 14:41 ` Johannes Weiner
2011-09-23 14:41 ` Johannes Weiner
2011-09-28 5:57 ` Minchan Kim
2011-09-28 5:57 ` Minchan Kim
2011-09-28 5:57 ` Minchan Kim
2011-09-28 9:27 ` Mel Gorman
2011-09-28 9:27 ` Mel Gorman
2011-09-28 9:27 ` Mel Gorman
2011-09-23 14:42 ` [patch 2/2/4] mm: try to distribute dirty pages fairly across zones Johannes Weiner
2011-09-23 14:42 ` Johannes Weiner
2011-09-23 14:42 ` Johannes Weiner
2011-09-28 5:56 ` Minchan Kim
2011-09-28 5:56 ` Minchan Kim
2011-09-28 5:56 ` Minchan Kim
2011-09-28 7:11 ` Johannes Weiner
2011-09-28 7:11 ` Johannes Weiner
2011-09-28 7:11 ` Johannes Weiner
2011-09-28 18:09 ` Minchan Kim
2011-09-28 18:09 ` Minchan Kim
2011-09-28 18:09 ` Minchan Kim
2011-09-28 9:36 ` Mel Gorman
2011-09-28 9:36 ` Mel Gorman
2011-09-28 9:36 ` Mel Gorman
2011-09-20 13:45 ` [patch 3/4] mm: filemap: pass __GFP_WRITE from grab_cache_page_write_begin() Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 14:25 ` Christoph Hellwig
2011-09-20 14:25 ` Christoph Hellwig
2011-09-20 14:25 ` Christoph Hellwig
2011-09-20 18:38 ` Rik van Riel
2011-09-20 18:38 ` Rik van Riel
2011-09-20 18:38 ` Rik van Riel
2011-09-20 18:40 ` Christoph Hellwig
2011-09-20 18:40 ` Christoph Hellwig
2011-09-20 18:40 ` Christoph Hellwig
2011-09-21 14:09 ` Johannes Weiner
2011-09-21 14:09 ` Johannes Weiner
2011-09-21 14:09 ` Johannes Weiner
2011-09-20 18:40 ` Rik van Riel
2011-09-20 18:40 ` Rik van Riel
2011-09-20 18:40 ` Rik van Riel
2011-09-21 14:34 ` Mel Gorman
2011-09-21 14:34 ` Mel Gorman
2011-09-21 14:34 ` Mel Gorman
2011-09-28 6:02 ` Minchan Kim
2011-09-28 6:02 ` Minchan Kim
2011-09-28 6:02 ` Minchan Kim
2011-09-20 13:45 ` [patch 4/4] Btrfs: pass __GFP_WRITE for buffered write page allocations Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:45 ` Johannes Weiner
2011-09-20 13:56 ` Johannes Weiner
2011-09-20 13:56 ` Johannes Weiner
2011-09-20 13:56 ` Johannes Weiner
2011-09-20 14:09 ` Josef Bacik
2011-09-20 14:09 ` Josef Bacik
2011-09-20 14:09 ` Josef Bacik
2011-09-20 14:14 ` Johannes Weiner
2011-09-20 14:14 ` Johannes Weiner
2011-09-20 14:14 ` Johannes Weiner
2011-09-20 18:41 ` Rik van Riel
2011-09-20 18:41 ` Rik van Riel
2011-09-20 18:41 ` 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=4E78DD10.4000900@redhat.com \
--to=riel@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jweiner@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.