On Fri, 23 Jun 2006, Hugh Dickins wrote:
>
> However, I've never understood why it should be fasttracked into
> 2.6.18: we usually let such patchsets cook for a cycle in -mm.
> 2.6.N-rc can get wider exposure than 2.6.(N-1)-mm, reveal problems
> missed all the while in -mm, but a cycle in -mm is still worthwhile.
Well, I've got two reasons to want to fast-track it:
- it's exactly what I wanted to see, so I'm obviously personally happy
with the patch
- the main _real_ issues I'd expect to surface are some subtle
performance issues when the kernel knows about more dirty pages, and
the dirty limit is thus _effectively_ different (never mind even the
page dirtying throttling itself - just the fact that we count the dirty
pages will mean that we'll see different throttling behaviour for
regular writes too in the presense of dirty)
Now, the first one is admittedly purely personal, but the second one boils
down to the fact that I think we want people to use it in order to find
these problems, and I suspect the -mm users are very uniform: it's
probably almost exclusively (kernel) developers rather than "normal
users".
> My pathetically slow responses have hindered Peter's good work, yes,
> but I don't think they've affected the overall appropriate timing.
No, I don't thinkthat has been the problem. I think the patches have
improved from the feedback from you and others, I just think we're quite
possible past the point where we simply would be better off with testing
than with arguing from a source perspective.
But maybe I'm just biased.
> Is there any particular reason why 2.6.18 rather than 2.6.19 be
> the release that fixes this issue that's been around forever?
My main worry has always been the effects of this on some strange load,
not the stability itself.
> And have we even seen stats for it yet? We know that it shouldn't
> affect the vast majority of loads (not mapping shared writable), but
> it won't be fixing any problem on them either; and we've had reports
> that it does fix the issue, but at what perf cost? (I may have missed)
_Exactly_. This is why I think earlier rather than later is better.
Sitting in -mm won't get us any new unexpected load cases - only more of
the same that hasn't shown any huge flags per se (although the dirty limit
discussion clearly shows people are at least thinking about it).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
