All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.