From: "Hua Zhong" <hzhong@gmail.com>
To: "'Linus Torvalds'" <torvalds@linux-foundation.org>,
"'Trenton D. Adams'" <trenton.d.adams@gmail.com>
Cc: "'Chris Mason'" <chris.mason@oracle.com>,
"'Theodore Tso'" <tytso@mit.edu>,
"'Jens Axboe'" <jens.axboe@oracle.com>,
"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 0/8][RFC] IO latency/throughput fixes
Date: Mon, 6 Apr 2009 22:23:31 -0700 [thread overview]
Message-ID: <006f01c9b741$00c70510$02550f30$@com> (raw)
In-Reply-To: <alpine.LFD.2.00.0904062156180.4010@localhost.localdomain>
The (small) set of people that rely on "ordered" understand
the problem, as long as they are aware of the change (no, I
don't think reading through all changelogs from their old
kernel to the new one is a realistic option).
So a config option should be good enough to get them to notice
the change (I assume a missing default will force them to
choose an option), and therefore explicitly add the -o ordered
option to their scripts.
On the other hand a run-time tunable has no real point.
> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
> Sent: Monday, April 06, 2009 10:02 PM
> To: Trenton D. Adams
> Cc: Chris Mason; Theodore Tso; Hua Zhong; Jens Axboe; Linux Kernel
> Mailing List
> Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes
>
>
>
> On Mon, 6 Apr 2009, Trenton D. Adams wrote:
> >
> > What about a procfs setting instead? Is there a policy about why
> > something should be in procfs or /sys, or as a kernel config option?
> > That's basically as small as the patch you just made, right?
>
> I'm never really against making things dynamically tunable, but this
> already was, and that wasn't really the issue.
>
> Sure, you can just re-mount your filesystem with different options.
> That's
> what I did while testing - my /home is on a drive of its own, so I
> would
> just log out and as root unmount and re-mount with
> data=ordered/writeback,
> and log in and test again.
>
> So dynamic tuning is good. But at the same time, having a tuning option
> is
> _never_ an excuse for not getting the default right in the first place.
> It's just a cop-out to say "hey, the default may be wrong for you, but
> you
> can always tune it locally with XYZ".
>
> The thing is, almost nobody does that. Partly because it needs effort
> and
> knowledge, partly because after a few years the number of tuning knobs
> are
> in the hundreds for every little thing.
>
> So instead, leave the tuning for the _really_ odd cases (if you use
> your
> machine as an IP router, you hopefully know enough to tune it if you
> really care). Not for random general-purpose "use for whatever" kind of
> thing.
>
> > I'm just thinking that something like this, where people want one
> > thing or the other, but may not know it when they install Linux,
> might
> > like to change it realtime. Especially if they are a Linux newbie,
> > and don't know how to compile their own kernel. Or don't have time
> to
> > maintain their own kernel installs.
>
> Oh absolutely. I'm not expecting people to compile their own kernels.
> I'm
> expecting that within a few months, most modern distributions will have
> (almost by mistake) gotten a new set of saner defaults, and anybody who
> keeps their machine up-to-date will see a smoother experience without
> ever
> even realizing _why_.
>
> Linus
next prev parent reply other threads:[~2009-04-07 5:24 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 12:48 [PATCH 0/8][RFC] IO latency/throughput fixes Jens Axboe
2009-04-06 12:48 ` [PATCH 1/8] block: change the request allocation/congestion logic to be sync/async based Jens Axboe
2009-04-06 12:48 ` [PATCH 2/8] Add WRITE_SYNC_PLUG and SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 3/8] block: fsync_buffers_list() should use SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 4/8] jbd: use WRITE_SYNC_PLUG instead of WRITE_SYNC Jens Axboe
2009-04-06 12:48 ` [PATCH 5/8] jbd2: " Jens Axboe
2009-04-06 12:48 ` [PATCH 6/8] block: enabling plugging on SSD devices that don't do queuing Jens Axboe
2009-04-06 12:48 ` [PATCH 7/8] block: Add flag for telling the IO schedulers NOT to anticipate more IO Jens Axboe
2009-04-06 12:48 ` [PATCH 8/8] block: switch sync_dirty_buffer() over to WRITE_SYNC Jens Axboe
2009-04-06 13:04 ` [PATCH 0/8][RFC] IO latency/throughput fixes Jens Axboe
2009-04-06 13:13 ` Jens Axboe
2009-04-06 15:37 ` Linus Torvalds
2009-04-06 16:57 ` Jens Axboe
2009-04-07 3:28 ` Chris Mason
2009-04-06 15:04 ` Linus Torvalds
2009-04-06 15:10 ` Jens Axboe
2009-04-06 15:45 ` Linus Torvalds
2009-04-06 17:01 ` Jens Axboe
2009-04-06 18:31 ` Theodore Tso
2009-04-06 19:57 ` Linus Torvalds
2009-04-06 20:10 ` Linus Torvalds
2009-04-06 21:26 ` Theodore Tso
2009-04-06 20:12 ` Hua Zhong
2009-04-06 20:20 ` Linus Torvalds
2009-04-06 21:19 ` Theodore Tso
2009-04-06 21:35 ` Hua Zhong
2009-04-06 22:04 ` Ray Lee
2009-04-06 22:17 ` Linus Torvalds
2009-04-06 23:10 ` Linus Torvalds
2009-04-07 7:51 ` Geert Uytterhoeven
2009-04-07 10:36 ` Ingo Molnar
2009-04-07 14:10 ` Diego Calleja
2009-04-08 12:04 ` Ingo Molnar
2009-04-08 12:56 ` Denys Vlasenko
2009-04-08 13:27 ` Ingo Molnar
2009-04-07 13:35 ` Mark Lord
2009-04-07 14:33 ` Linus Torvalds
2009-04-07 19:24 ` Mark Lord
2009-04-07 19:45 ` Jeff Garzik
2009-04-07 20:53 ` Mike Galbraith
2009-04-09 2:40 ` Eric Sandeen
2009-04-09 14:01 ` Ric Wheeler
2009-04-06 22:25 ` Hua Zhong
2009-04-06 22:48 ` Ray Lee
2009-04-06 22:52 ` Hua Zhong
2009-04-06 23:19 ` Alan Cox
2009-04-07 3:52 ` Chris Mason
2009-04-07 4:13 ` Trenton D. Adams
2009-04-07 4:27 ` Linus Torvalds
2009-04-07 4:48 ` Trenton D. Adams
2009-04-07 5:02 ` Linus Torvalds
2009-04-07 5:23 ` Hua Zhong [this message]
2009-04-07 6:27 ` Trenton D. Adams
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='006f01c9b741$00c70510$02550f30$@com' \
--to=hzhong@gmail.com \
--cc=chris.mason@oracle.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trenton.d.adams@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox