On Tuesday 22 July 2003 15:59, Andrea Arcangeli wrote:
Hi Andrea,
> performance degradation when? note that we're only talking about
> contigous I/O here, not contest. I can't measure any performance
> degradation during contigous I/O and if something it could be explained
> by the now shorter queue, but you tried enlarging it and it went even
> slower (this was good btw, confirming a larger queue was completely
> worthless and it only hurts the VM without providing any I/O bandwidth
> pipelining benefit). The elevator-lowlatency should have no other effect
> other than a shorter queue during pure contigous I/O.
Well, contigous I/O isn't a big problem, though I saw performance degradation
in contigous I/O. The problem is, that I still see mouse stops while heavy
I/O, that I still see keyboard stops while heavy I/O, X is dog slow while
heavy I/O (renicing X to -20 doesn't really help). I really miss the 2.4.18
time where this wasn't a problem at all!
Contest was not the reason. An easy reproducable scenario is:
dd if=/dev/zero of=/home/largefile bs=16384 count=131072
This will kill your mouse, keyboard and X. The only "workaround" not to see
mouse stops, keyboard stops and X dogstyle was decreasing nr_requests from
128 to 4. Anything higher resulted in pauses (e.g. 8 for nr_requests).
Maybe SCSI behaves totally different, dunno. ATM I don't have SCSI around to
test it, only IDE (ATA100/ATA133).
I've tested this too for .22-pre7, changing "MAX_NR_REQUESTS 1024" to "4". And
now the big surprise: Still mouse stops, keyboard stops while, e.g. the above
dd command, but with, for sure, very low throughput. So throughput dropping
is not the problem here at all. I have very very low throughput but still
pauses/stops. How is this possible? I am very confused about the code :-(
> > > can you try with data=writeback (or ext2) or hdparm -W1 and see if you
> > > can still see the same delta between the two kernels? (careful with -W1
> > > as it invalidates journaling)
> > Yes, I'll do it later this day.
> please try plain ext2, this sounds like some fs effect of some sort. The
> fs must throttle on the shorter queue or seek differently somehow.
well, ext2 does not make any difference :-(
I thought trying out q->full from Chris would make any difference. I am quite
sure that it must be a merge error by me, otherwise I cannot explain why
q->full kills my X-windows for tons of seconds during a "make -j16 bzImage
modules" I get stops of the whole system too for some seconds every 30
seconds or so. Ripped out q->full (not just disabling via elvtune -b 0) fixed
at least that behaviour.
Another funny thing, not dependant on q->full, is, that VMware needs over 1
Minute to start up with a Windows 2000 in it where w/o the lowlat elevator it
needs ~30 seconds or less to start up completely. VMware has reads/writes
during the startup about _max_ of 500kb/s. Before it went up to 10mb/s.
Now we should decide if it's either a bug in the kernel or a bug in VMware ;))
> > Sorry for my late reply. I've been very busy.
> No problem ;)
ok :) thnx. Sorry again for the delay, but I wanted to be sure about the
reports so I had to test many things out first.
Hmm, I am a bit afraid that no one else noticed this yet. This reminds be back
to over a year ago where I reported I/O stalls/pauses/stops with 2.4.19-pre's
and no one noticed that but you after some time. A 'real' fix for that came up
over one year later and some days before we had a big discussion about it with
many people involved noticing it too.
Don't get me wrong Andrea and Chris :) .. but I am quite disappointed about
current Linux for the Desktop. 2.4 has I/O problems, 2.6 has Scheduler
problems, 2 things I cannot live with for my Desktop. Maybe Linus is right
when he said, Linux may be Desktop ready in 2006.
Any suggestions what I can do to help to fix that silly behaviour? I really
really want a usable 2.4 tree again (read: 2.4.22 final) :)
P.S.: I've CC'ed Nick.
ciao, Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:22 EST