public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: "Gérard Roudier" <groudier@free.fr>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: The good, the bad & the ugly (or VM, block devices, and SCSI :-)
Date: Thu, 01 Nov 2001 22:31:55 +0100	[thread overview]
Message-ID: <200111012131.WAA28302@webserver.ithnet.com> (raw)
In-Reply-To: <20011101142507.S1471-100000@gerard>

> The TCQ-depth shouldn't matter as long as only the CD drive is      
accessed                                                              
> given that such devices are unlikely to support tagged commands.    
> Nevertheless, you should check your boot log messages and also      
compare the                                                           
> thoughput negotiation between controller and devices.               
                                                                      
Hm, I am not so sure about TCQ not having _any_ influence. Remember I 
read the CD _and_ write the image to disk (the U160 IBM). So it could 
well be that the results are an accummulation of two bad performing   
things on aic7xxx: the CD read and the disk write.                    
                                                                      
Hear my risky analysis of the problem:                                
The aic7xxx interrupt handler is the cause. It may be that it "wants" 
to much, meaning its hanging hard on its business eating up resources 
(and gaining nothing for it), and therefore playing bad with the      
network interrupt handling _and_ its own higher layer code.           
Or (another pure guess) its busted by its own memory handling         
strategy. I see during the cd read 2 or 3 times simple "freezes" (no  
bug deal, but remarkable) where the systems seems to "hang" for just  
1-2 seconds. symbios code does not show this, but runs smoothly       
through the whole test. This is _not_ related to VM, there is a lot   
free mem during these "small-freezes".                                
                                                                      
> [...]                                                               
> Indeed, the configs look very similar.                              
                                                                      
Believe me, it is.                                                    
                                                                      
> > I can. I did a whole lot of such tests during my former job for a 
company                                                               
> > producing scsi-controllers.                                       
>                                                                     
> Interesting, if you can elaborate...                                
                                                                      
These were the g'old Commodore times (Amiga). :-) Ask me off-list If  
you're interested ...                                                 
                                                                      
> > > Thanks, anyway, for your report.                                
> >                                                                   
> > Well, as already said, take it as a hint that your part of the    
story performs                                                        
> > pretty well.                                                      
> > ;-)                                                               
>                                                                     
> The sym53c8xx driver beeing faster than the aic7xxx with CD devices 
using                                                                 
> Ultra160 controllers is an amuzing result. :)                       
> I still cannot beleive that it is due to a aic7xxx driver fault. If 
I had                                                                 
> such a controller, I would for sure check that, but I haven't any.  
                                                                      
Hm, if I find some spare time, I try to proof it. I am almost sure it 
has nothing to do with hardware. Maybe I am going to earn another red 
herring from linus, which turns out to be red lobster afterwards ;-)  
Keep smiling, we are all having fun here :-)                          
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      
                                                                      
                                                                      

  reply	other threads:[~2001-11-01 21:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-31 15:45 The good, the bad & the ugly (or VM, block devices, and SCSI :-) Stephan von Krawczynski
2001-10-31 17:29 ` Gérard Roudier
2001-11-01 14:10   ` Stephan von Krawczynski
2001-11-01 14:01     ` Gérard Roudier
2001-11-01 21:31       ` Stephan von Krawczynski [this message]
2001-11-01 10:40 ` Sebastian Benoit
2001-11-01 14:14   ` Stephan von Krawczynski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200111012131.WAA28302@webserver.ithnet.com \
    --to=skraw@ithnet.com \
    --cc=groudier@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox