linux-kernel - RE: [PATCH 0/8][RFC] IO latency/throughput fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Apr 2009 22:23:31 -0700
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Linus Torvalds'" <torvalds@...ux-foundation.org>,
	"'Trenton D. Adams'" <trenton.d.adams@...il.com>
Cc:	"'Chris Mason'" <chris.mason@...cle.com>,
	"'Theodore Tso'" <tytso@....edu>,
	"'Jens Axboe'" <jens.axboe@...cle.com>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/8][RFC] IO latency/throughput fixes

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/