All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: linux-kernel@vger.kernel.org, groudier@club-internet.fr
Subject: Re: Adaptec vs Symbios performance
Date: Sun, 04 Nov 2001 04:50:43 +0100	[thread overview]
Message-ID: <200111040350.EAA22275@webserver.ithnet.com> (raw)
In-Reply-To: <200111032318.fA3NIQY62745@aslan.scsiguy.com>

> >Hello Justin, hello Gerard                                         
                                                                      
> >                                                                   
                                                                      
> >I am looking currently for reasons for bad behaviour of aic7xxx    
driver                                                                
> >in an shared interrupt setup and general not-nice behaviour of the 
                                                                      
> >driver regarding multi-tasking environment.                        
                                                                      
>                                                                     
> Can you be more specific?                                           
                                                                      
Yes, of course :-)                                                    
What I am seeing over here is that aic7xxx is _significantly_ slower  
than symbios _in the exact same context_. I refused to use the "new"  
driver as long as possible because I had (right from the first test)  
the "feeling" that it hurts the machine overall performance in some   
way, meaning the box seems _slow_ and less responsive than it was with
the old aic driver. When I directly compared it with symbios (LSI     
Logic hardware sold from Tekram) I additionaly found out, that it     
seems to hurt the interrupt performance of a network card sharing its 
interrupt with the aic which again does not happen with symbios. I    
have already seen such behaviour before, on merely every driver I     
formerly wrote for shared interrupt systems I had to fill in code that
_prevents_ lockout of other interrupt users due to indefinitely       
walking through the own code in high load situation.                  
But, of course, you _know_ this. Nobody writes a driver like new      
aic7xxx _and_ doesn't know :-)                                        
My guess is that this knowledge made you enter the comment I ripped   
from your code about using bottom half handler instead of dealing with
workload in a hardware interrupt. Again, I have to no extent read your
code completely or the like. I simply tried to find the hardware      
interrupt routine and look if it does significant eli (EverLasting    
Interrupt ;-) stuff - and I found your comment.                       
Can you re-comment from todays point of view?                         
                                                                      
> >This is nice. I cannot read the complete code around it (it is     
derived                                                               
> >from aic7xxx_linux.c) but if I understand the naming and comments  
                                                                      
> >correct, some workload is done inside the hardware interrupt (which
                                                                      
> >shouldn't), which would very much match my tests showing bad       
overall                                                               
> >performance behaviour. Obviously this code is old (read the        
comment)                                                              
> >and needs reworking.                                               
                                                                      
> >Comments?                                                          
                                                                      
>                                                                     
> I won't comment on whether deferring this work until outside of     
> an interrupt context would help your "problem" until I understand   
> what you are complaining about. 8-)                                 
                                                                      
In a nutshell:                                                        
a) long lasting interrupt workloads prevent normal process activity   
(creating latency and sticky behaviour)                               
b) long lasting interrupt workloads play bad on other interrupt users 
(e.g. on the same shared interrupt)                                   
I can see _both_ comparing aic with symbios.                          
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      
                                                                      
                                                                      

       reply	other threads:[~2001-11-04  3:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200111032318.fA3NIQY62745@aslan.scsiguy.com>
2001-11-04  3:50 ` Stephan von Krawczynski [this message]
2001-11-04  5:47   ` Adaptec vs Symbios performance Justin T. Gibbs
2001-11-04  5:23     ` Gérard Roudier
2001-11-04 14:17     ` Stephan von Krawczynski
2001-11-04 18:10       ` Justin T. Gibbs
2001-11-04 18:35         ` Stephan von Krawczynski
2001-11-04 16:31           ` Gérard Roudier
2001-11-04 19:13           ` Justin T. Gibbs
2001-11-04 19:56             ` Stephan von Krawczynski
2001-11-04 20:43               ` Justin T. Gibbs
2001-11-05 12:18                 ` Matthias Andree
2001-11-04 19:02         ` Stephan von Krawczynski
2001-11-02 22:42 Google's mm problem - not reproduced on 2.4.13 Ben Smith
2001-11-03 22:53 ` Adaptec vs Symbios performance Stephan von Krawczynski
2001-11-03 23:01   ` arjan

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=200111040350.EAA22275@webserver.ithnet.com \
    --to=skraw@ithnet.com \
    --cc=gibbs@scsiguy.com \
    --cc=groudier@club-internet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.