From: Wu Fengguang <fengguang.wu@intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Theodore Ts'o" <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mel Gorman <mel@csn.ul.ie>, Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Chris Mason <chris.mason@oracle.com>,
Christoph Hellwig <hch@lst.de>,
"Li, Shaohua" <shaohua.li@intel.com>
Subject: Re: [PATCH 00/17] [RFC] soft and dynamic dirty throttling limits
Date: Wed, 13 Oct 2010 11:23:42 +0800 [thread overview]
Message-ID: <20101013032342.GA10020@localhost> (raw)
In-Reply-To: <20101013030733.GV4681@dastard>
On Wed, Oct 13, 2010 at 11:07:33AM +0800, Dave Chinner wrote:
> On Tue, Oct 12, 2010 at 10:17:16AM -0400, Christoph Hellwig wrote:
> > Wu, what's the state of this series? It looks like we'll need it
> > rather sooner than later - try to get at least the preparations in
> > ASAP would be really helpful.
>
> Not ready in it's current form. This load (creating millions of 1
> byte files in parallel):
>
> $ /usr/bin/time ./fs_mark -D 10000 -S0 -n 100000 -s 1 -L 63 \
> > -d /mnt/scratch/0 -d /mnt/scratch/1 \
> > -d /mnt/scratch/2 -d /mnt/scratch/3 \
> > -d /mnt/scratch/4 -d /mnt/scratch/5 \
> > -d /mnt/scratch/6 -d /mnt/scratch/7
>
> Locks up all the fs_mark processes spinning in traces like the
> following and no further progress is made when the inode cache
> fills memory.
Dave, thanks for the testing! I'll try to reproduce it and check
what's going on.
Thanks,
Fengguang
> [ 2601.452017] fs_mark R running task 0 2303 2235 0x00000008
> [ 2601.452017] ffff8801188f7878 ffffffff8103e2c9 ffff8801188f78a8 0000000000000000
> [ 2601.452017] 0000000000000002 ffff8801129e21c0 ffff880002fd44c0 0000000000000000
> [ 2601.452017] ffff8801188f78b8 ffffffff810a9a08 ffff8801188f78e8 ffffffff810a98e5
> [ 2601.452017] Call Trace:
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff810b9e00>] ? __lock_acquire+0x330/0x14d0
> [ 2601.452017] [<ffffffff810a9a94>] ? local_clock+0x34/0x80
> [ 2601.452017] [<ffffffff81061cc8>] ? pvclock_clocksource_read+0x58/0xd0
> [ 2601.452017] [<ffffffff81061cc8>] ? pvclock_clocksource_read+0x58/0xd0
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810bb054>] ? lock_acquire+0xb4/0x140
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff81698ea2>] ? prop_get_global+0x32/0x50
> [ 2601.452017] [<ffffffff81699230>] ? prop_fraction_percpu+0x30/0xa0
> [ 2601.452017] [<ffffffff8111af3b>] ? bdi_dirty_limit+0x9b/0xe0
> [ 2601.452017] [<ffffffff8111bbd8>] ? balance_dirty_pages_ratelimited_nr+0x178/0x580
> [ 2601.452017] [<ffffffff81ad440b>] ? _raw_spin_unlock+0x2b/0x40
> [ 2601.452017] [<ffffffff8117ccd5>] ? __mark_inode_dirty+0xc5/0x230
> [ 2601.452017] [<ffffffff811114d5>] ? iov_iter_copy_from_user_atomic+0x95/0x170
> [ 2601.452017] [<ffffffff811118fc>] ? generic_file_buffered_write+0x1cc/0x270
> [ 2601.452017] [<ffffffff81492f2f>] ? xfs_file_aio_write+0x79f/0xaf0
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff81157cca>] ? do_sync_write+0xda/0x120
> [ 2601.452017] [<ffffffff8112e20c>] ? might_fault+0x5c/0xb0
> [ 2601.452017] [<ffffffff81669f7f>] ? security_file_permission+0x1f/0x80
> [ 2601.452017] [<ffffffff81157fb8>] ? vfs_write+0xc8/0x180
> [ 2601.452017] [<ffffffff81158904>] ? sys_write+0x54/0x90
> [ 2601.452017] [<ffffffff81037072>] ? system_call_fastpath+0x16/0x1b
>
> This is on an 8p/4GB RAM VM.
>
> FWIW, this one test now has a proven record of exposing writeback,
> VM and filesystem regressions, so I'd suggest that anyone doing any
> sort of work that affects writeback adds it to their test matrix....
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mel Gorman <mel@csn.ul.ie>, Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Chris Mason <chris.mason@oracle.com>,
Christoph Hellwig <hch@lst.de>,
"Li, Shaohua" <shaohua.li@intel.com>
Subject: Re: [PATCH 00/17] [RFC] soft and dynamic dirty throttling limits
Date: Wed, 13 Oct 2010 11:23:42 +0800 [thread overview]
Message-ID: <20101013032342.GA10020@localhost> (raw)
In-Reply-To: <20101013030733.GV4681@dastard>
On Wed, Oct 13, 2010 at 11:07:33AM +0800, Dave Chinner wrote:
> On Tue, Oct 12, 2010 at 10:17:16AM -0400, Christoph Hellwig wrote:
> > Wu, what's the state of this series? It looks like we'll need it
> > rather sooner than later - try to get at least the preparations in
> > ASAP would be really helpful.
>
> Not ready in it's current form. This load (creating millions of 1
> byte files in parallel):
>
> $ /usr/bin/time ./fs_mark -D 10000 -S0 -n 100000 -s 1 -L 63 \
> > -d /mnt/scratch/0 -d /mnt/scratch/1 \
> > -d /mnt/scratch/2 -d /mnt/scratch/3 \
> > -d /mnt/scratch/4 -d /mnt/scratch/5 \
> > -d /mnt/scratch/6 -d /mnt/scratch/7
>
> Locks up all the fs_mark processes spinning in traces like the
> following and no further progress is made when the inode cache
> fills memory.
Dave, thanks for the testing! I'll try to reproduce it and check
what's going on.
Thanks,
Fengguang
> [ 2601.452017] fs_mark R running task 0 2303 2235 0x00000008
> [ 2601.452017] ffff8801188f7878 ffffffff8103e2c9 ffff8801188f78a8 0000000000000000
> [ 2601.452017] 0000000000000002 ffff8801129e21c0 ffff880002fd44c0 0000000000000000
> [ 2601.452017] ffff8801188f78b8 ffffffff810a9a08 ffff8801188f78e8 ffffffff810a98e5
> [ 2601.452017] Call Trace:
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff810b9e00>] ? __lock_acquire+0x330/0x14d0
> [ 2601.452017] [<ffffffff810a9a94>] ? local_clock+0x34/0x80
> [ 2601.452017] [<ffffffff81061cc8>] ? pvclock_clocksource_read+0x58/0xd0
> [ 2601.452017] [<ffffffff81061cc8>] ? pvclock_clocksource_read+0x58/0xd0
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810bb054>] ? lock_acquire+0xb4/0x140
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff81698ea2>] ? prop_get_global+0x32/0x50
> [ 2601.452017] [<ffffffff81699230>] ? prop_fraction_percpu+0x30/0xa0
> [ 2601.452017] [<ffffffff8111af3b>] ? bdi_dirty_limit+0x9b/0xe0
> [ 2601.452017] [<ffffffff8111bbd8>] ? balance_dirty_pages_ratelimited_nr+0x178/0x580
> [ 2601.452017] [<ffffffff81ad440b>] ? _raw_spin_unlock+0x2b/0x40
> [ 2601.452017] [<ffffffff8117ccd5>] ? __mark_inode_dirty+0xc5/0x230
> [ 2601.452017] [<ffffffff811114d5>] ? iov_iter_copy_from_user_atomic+0x95/0x170
> [ 2601.452017] [<ffffffff811118fc>] ? generic_file_buffered_write+0x1cc/0x270
> [ 2601.452017] [<ffffffff81492f2f>] ? xfs_file_aio_write+0x79f/0xaf0
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff81060edc>] ? kvm_clock_read+0x1c/0x20
> [ 2601.452017] [<ffffffff8103e2c9>] ? sched_clock+0x9/0x10
> [ 2601.452017] [<ffffffff810a98e5>] ? sched_clock_local+0x25/0x90
> [ 2601.452017] [<ffffffff81157cca>] ? do_sync_write+0xda/0x120
> [ 2601.452017] [<ffffffff8112e20c>] ? might_fault+0x5c/0xb0
> [ 2601.452017] [<ffffffff81669f7f>] ? security_file_permission+0x1f/0x80
> [ 2601.452017] [<ffffffff81157fb8>] ? vfs_write+0xc8/0x180
> [ 2601.452017] [<ffffffff81158904>] ? sys_write+0x54/0x90
> [ 2601.452017] [<ffffffff81037072>] ? system_call_fastpath+0x16/0x1b
>
> This is on an 8p/4GB RAM VM.
>
> FWIW, this one test now has a proven record of exposing writeback,
> VM and filesystem regressions, so I'd suggest that anyone doing any
> sort of work that affects writeback adds it to their test matrix....
--
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:[~2010-10-13 3:23 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-12 15:49 [PATCH 00/17] [RFC] soft and dynamic dirty throttling limits Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 01/17] writeback: remove the internal 5% low bound on dirty_ratio Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-13 9:23 ` Johannes Weiner
2010-09-13 9:23 ` Johannes Weiner
2010-09-13 9:51 ` Mel Gorman
2010-09-13 9:51 ` Mel Gorman
2010-09-13 9:57 ` Wu Fengguang
2010-09-13 9:57 ` Wu Fengguang
2010-09-13 10:10 ` Mel Gorman
2010-09-13 10:10 ` Mel Gorman
2010-09-12 15:49 ` [PATCH 02/17] writeback: IO-less balance_dirty_pages() Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-13 8:45 ` Dave Chinner
2010-09-13 8:45 ` Dave Chinner
2010-09-13 11:38 ` Wu Fengguang
2010-09-13 11:38 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 03/17] writeback: per-task rate limit to balance_dirty_pages() Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 04/17] writeback: quit throttling when bdi dirty/writeback pages go down Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 05/17] writeback: quit throttling when signal pending Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 20:46 ` Neil Brown
2010-09-12 20:46 ` Neil Brown
2010-09-13 1:55 ` Wu Fengguang
2010-09-13 1:55 ` Wu Fengguang
2010-09-13 3:21 ` Neil Brown
2010-09-13 3:21 ` Neil Brown
2010-09-13 3:48 ` Wu Fengguang
2010-09-13 3:48 ` Wu Fengguang
2010-09-14 8:23 ` KOSAKI Motohiro
2010-09-14 8:23 ` KOSAKI Motohiro
2010-09-14 8:33 ` Wu Fengguang
2010-09-14 8:33 ` Wu Fengguang
2010-09-14 8:44 ` KOSAKI Motohiro
2010-09-14 8:44 ` KOSAKI Motohiro
2010-09-14 9:17 ` Wu Fengguang
2010-09-14 9:17 ` Wu Fengguang
2010-09-14 9:25 ` KOSAKI Motohiro
2010-09-14 9:25 ` KOSAKI Motohiro
2010-09-12 15:49 ` [PATCH 06/17] writeback: move task dirty fraction to balance_dirty_pages() Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 07/17] writeback: add trace event for balance_dirty_pages() Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 08/17] writeback: account per-bdi accumulated written pages Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:59 ` Wu Fengguang
2010-09-12 15:59 ` Wu Fengguang
2010-09-14 8:32 ` KOSAKI Motohiro
2010-09-14 8:32 ` KOSAKI Motohiro
2010-09-12 15:49 ` [PATCH 09/17] writeback: bdi write bandwidth estimation Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 10/17] writeback: show bdi write bandwidth in debugfs Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 11/17] writeback: make nr_to_write a per-file limit Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 12/17] writeback: scale IO chunk size up to device bandwidth Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 13/17] writeback: reduce per-bdi dirty threshold ramp up time Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 16:15 ` Wu Fengguang
2010-09-12 16:15 ` Wu Fengguang
2010-09-12 15:49 ` [PATCH 14/17] vmscan: add scan_control.priority Wu Fengguang
2010-09-12 15:49 ` Wu Fengguang
2010-09-12 15:50 ` [PATCH 15/17] mm: lower soft dirty limits on memory pressure Wu Fengguang
2010-09-12 15:50 ` Wu Fengguang
2010-09-13 9:40 ` Wu Fengguang
2010-09-13 9:40 ` Wu Fengguang
2010-09-12 15:50 ` [PATCH 16/17] mm: create /vm/dirty_pressure in debugfs Wu Fengguang
2010-09-12 15:50 ` Wu Fengguang
2010-09-12 15:50 ` [PATCH 17/17] writeback: consolidate balance_dirty_pages() variable names Wu Fengguang
2010-09-12 15:50 ` Wu Fengguang
2010-10-12 14:17 ` [PATCH 00/17] [RFC] soft and dynamic dirty throttling limits Christoph Hellwig
2010-10-12 14:17 ` Christoph Hellwig
2010-10-13 3:07 ` Dave Chinner
2010-10-13 3:07 ` Dave Chinner
2010-10-13 3:23 ` Wu Fengguang [this message]
2010-10-13 3:23 ` Wu Fengguang
2010-10-13 8:26 ` Wu Fengguang
2010-10-13 8:26 ` Wu Fengguang
2010-10-13 9:26 ` Dave Chinner
2010-10-13 9:26 ` Dave Chinner
2010-11-01 6:24 ` Dave Chinner
2010-11-01 6:24 ` Dave Chinner
2010-11-04 3:41 ` Wu Fengguang
2010-11-04 3:41 ` Wu Fengguang
2010-11-04 12:48 ` Dave Chinner
2010-11-04 12:48 ` Dave Chinner
2010-11-04 13:12 ` Christoph Hellwig
2010-11-04 13:12 ` Christoph Hellwig
2010-11-05 14:56 ` Wu Fengguang
2010-11-05 14:56 ` Wu Fengguang
2010-11-06 10:42 ` Dave Chinner
2010-11-06 10:42 ` Dave Chinner
2010-10-14 13:12 ` Wu Fengguang
2010-10-14 13:12 ` Wu Fengguang
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=20101013032342.GA10020@localhost \
--to=fengguang.wu@intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=riel@redhat.com \
--cc=shaohua.li@intel.com \
--cc=tytso@mit.edu \
/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.