[lkml]   [2007]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/23] per device dirty throttling -v8
Ingo Molnar wrote:

> || ...For me, I would say 50% is not enough to describe the _visible_
> || benefits... Not talking any specific number but past 10sec-1min+
> || lagging in X is history, it's gone and I really don't miss it that
> || much... :-) Cannot reproduce even a second long delay anymore in
> || window focusing under considerable load as it's basically
> || instantaneous (I can see that it's loaded but doesn't affect the
> || feeling of responsiveness I'm now getting), even on some loads that I
> || couldn't previously even dream of... [...]
> we really have to ask ourselves whether the "process" is correct if
> advantages to the user of this order of magnitude can be brushed aside
> with simple "this breaks binary-only HSM" and "it's not standards
> compliant" arguments.
Being standards compliant is not an argument it's a design goal, a
requirement. Standards compliance is like pregant, you are or you're
not. And to deliberately ignore standards for speed is saying "it's too
hard to do it right, I'll do it wrong and it will be faster." The answer
is to do it smarter, with solutions like relatime (which can be enhanced
as Linus noted) which provide performance benefits without ignoring
standards, or use of a filesystem which does a better job. But when it
goes in the kernel the choice of having per-filesystem behavior either
vanishes or becomes an exercise in complex and as-yet unwritten mount

There are certainly ways to improve ext3, not journaling atime updates
would certainly be one, less frequent updates of dirty inodes, whatever.
But if a user wants to give up standards compliance it should be a
deliberate choice, not something which the average user will not
understand or learn to do.

Bill Davidsen <>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-08 20:25    [W:0.173 / U:11.664 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site