>On Wed, 14 Jun 2000, Andrea Arcangeli wrote:
>> On Tue, 13 Jun 2000, Rik van Riel wrote:
and they wrote, and they wrote. What is bothering me about this
discussion is this:
I'm no wizard or even an expert when it comes to the VM system, but in
all the messages I've seen about this since things started changing
post 2.3.51, I have never seen significant attention being paid to the
subject of this message:
streaming I/O
Rik, Andrea, Juan and others working on VM have been doing an
apparently great job of slowly improving the VM performance to deal
with a variety of interesting cases. So far, however, there seems to
be little focus on what the design is doing to systems that just want
to stream large quantities of data to and from the disk.
Since 2.3.51 (and 2.2.{10+/-4}), the VM systems in both the "stable"
kernel and the "development" kernel have ruined streaming I/O
performance. Every so often, someone comes up with a little patch that
gets things somewhat better, and then there is another significant
redesign of the some substantial part of the VM system, and presto,
its broken again.
I have been patiently watching the attempts to fix streaming I/O
performance, and nothing that I have seen in messages from Andrea,
Rik or Juan suggest to me that we're even in the general vicinity of
the right answer. We seem to have a VM system that is much more
concerned with behaviours that are not typical of streaming i/o, and
have somehow ended up with a design that increasingly appears to be
fundamentally inimical to decent, reliable streaming I/O.
I understand the rationale for this going on in the development
kernel, but I am flabbergasted that anyone was allowed to do this to
the stable series. Its still not clear 2.2.17 will really work as well
as 2.2.{<15}, and even that did not work as well as 2.3.51.
At one point, I could tie up a huge percentage of my RAM with the
cache, and still get phenomenal performance from programs. For a month
or two now, I have been unable to get anything close to this
behaviour, and I don't see any evidence that either the current VM
design or the classzone stuff will get this back to the levels I saw.
The VM gang may yet pull the rabbit from the hat, and come up with
something that really does work well for all situations, but watching
this discussion, I increasingly feel like saying "Enough already: make
this hairy VM system a compile-time conditional for use when this
zoned stuff matters, and lets let people who don't need that kind of
behaviour use somethign similar to the 2.3.51 allocator/kswapd design
so that they can get decent streaming I/O performance".
Ordinarily, I'd see this as nothing to comment on - we are still
working on a development kernel, Linus' crazy decision to release
something with 2.4 in its name notwithstanding. But the fact that the
stable kernel series' performance has also been shredded leaves me
feeling very grumpy. I have a kick-ass gratis+libre application that
can replace hardware costing US$15K, and its impossible to run it
correctly without going back to 2.2.12 and adding Ingo's low latency
patches. The development kernel is a playground for new stuff, but
this time, the big kids have messed up our safe haven of stability as
well :)
If Rik or Juan can assure me that streaming I/O performance is a high
priority for them, I might feel better, but I see more concern about
boundary cases caused by quite different application patterns.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:30 EST