From: Wu Fengguang <fengguang.wu@intel.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Kautuk Consul <consul.kautuk@gmail.com>,
Mel Gorman <mgorman@suse.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH] writeback: Per-block device bdi->dirty_writeback_interval and bdi->dirty_expire_interval.
Date: Thu, 18 Aug 2011 20:35:23 +0800 [thread overview]
Message-ID: <20110818123523.GB1883@localhost> (raw)
In-Reply-To: <1313669702.6607.24.camel@sauron>
On Thu, Aug 18, 2011 at 08:14:57PM +0800, Artem Bityutskiy wrote:
> On Thu, 2011-08-18 at 17:48 +0800, Wu Fengguang wrote:
> > > For example, the user might want to write-back pages in smaller
> > > intervals to a block device which has a
> > > faster known writeback speed.
> >
> > That's not a complete rational. What does the user ultimately want by
> > setting a smaller interval? What would be the problems to the other
> > slow devices if the user does so by simply setting a small value
> > _globally_?
> >
> > We need strong use cases for doing such user interface changes.
> > Would you detail the problem and the pains that can only (or best)
> > be addressed by this patch?
>
> Here is a real use-case we had when developing the N900 phone. We had
> internal flash and external microSD slot. Internal flash is soldered in
> and cannot be removed by the user. MicroSD, in contrast, can be removed
> by the user.
>
> For the internal flash we wanted long intervals and relaxed limits to
> gain better performance.
Understand -- it's backed by the battery anyway.
Yeah it's a practical way. It might even optimize away some of the
writes if they are truncated some time later. It also allows possible
optimization of deferring the writes to user inactive periods.
However the ultimate optimization could be to prioritize READs over
WRITEs in the IO scheduler, so that async WRITEs have minimal impact
on normal operations. It's the only option for the MicroSD case,
anyway.
> For MicroSD we wanted very short intervals and tough limits to make sure
> that if the user suddenly removes his microSD (users do this all the
> time) - we do not lose data.
Pretty reasonable.
> The discussed capability would be very useful in that case, AFAICS.
Agreed.
> IOW, this is not only about fast/slow devices and how quickly you want
> to be able to sync the FS, this is also about data integrity guarantees.
In fact I never think it would matter for fast/slow devices. It's the
dirty_ratio/dirty_bytes interfaces that ask for improvement if care
about too many pages being cached.
The intervals interfaces are intended for data integrity and nothing
more.
Thanks,
Fengguang
--
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>
next prev parent reply other threads:[~2011-08-18 12:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFPAmTSrh4r71eQqW-+_nS2KFK2S2RQvYBEpa3QnNkZBy8ncbw@mail.gmail.com>
2011-08-18 9:48 ` [PATCH] writeback: Per-block device bdi->dirty_writeback_interval and bdi->dirty_expire_interval Wu Fengguang
2011-08-18 9:51 ` Wu Fengguang
2011-08-18 11:28 ` Kautuk Consul
2011-08-18 12:55 ` Wu Fengguang
2011-08-18 12:14 ` Artem Bityutskiy
2011-08-18 12:35 ` Wu Fengguang [this message]
2011-08-18 15:26 ` Kautuk Consul
2011-08-19 2:17 ` Wu Fengguang
2011-08-18 13:13 ` Wu Fengguang
2011-08-18 16:25 ` Kautuk Consul
2011-08-19 2:34 ` Wu Fengguang
2011-08-19 4:38 ` Kautuk Consul
2011-08-19 5:28 ` Wu Fengguang
2011-08-19 6:08 ` Wu Fengguang
2011-08-19 7:00 ` Kautuk Consul
2011-08-19 14:24 ` Wu Fengguang
2011-08-19 17:20 ` Kautuk Consul
2011-08-21 14:11 ` Wu Fengguang
2011-08-19 11:55 ` Artem Bityutskiy
2011-08-19 14:27 ` 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=20110818123523.GB1883@localhost \
--to=fengguang.wu@intel.com \
--cc=consul.kautuk@gmail.com \
--cc=david@fromorbit.com \
--cc=dedekind1@gmail.com \
--cc=jack@suse.cz \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
/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).