Re: 2.4.22pre6aa1

Chris Mason
2003-07-24T14:28:11Z

On Thu, 2003-07-24 at 08:27, Marc-Christian Petersen wrote:
> 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).

Ok, there's something fundamental we're missing here, the IDE boxes I
test on don't show this ;-) Can you setup a serial console and capture
sysrq-t during the pause? Or better yet setup kgdb.

What kind of keyboard/mouse do you have?

I'll give you an updated q->full patch on Monday, including the
__get_request_wait latency stats.

-chris