Re: 2.4.22pre6aa1

[Chris Mason <mason@suse.com>]

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