All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kallol Biswas <kallol@nucleodyne.com>
To: Mark Lord <liml@rtr.ca>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Fwd: Re: Performance figure for sx8 driver
Date: 12 Jun 2005 10:43:17 -0700	[thread overview]
Message-ID: <1118598197.25250.20.camel@driver> (raw)
In-Reply-To: <42AC6310.7030809@rtr.ca>

I have been investigating what the cause of performance loss could be.

I have noticed several things:

0) Setting to CARM_MAX_Q to 30 hangs. So we have been testing only with
CARM_MAX_Q == 1. The firmware has not been updated yet.

1) If we keep on increasing number of SATA disks, hdparm does not get
multiplied total read performance (hdparm -t ....).

With a Maxtor 60 GB disk with 8MB cache we get 50Mb/sec. If we put
two disks we get 35 on each. Total  70MB/sec. If we put more
then total does not get above 70MB/sec.

It  looks like that a part of the driver serializes the commands.
We have a 32 processor MIPS based system.

2) It looks like that there is while(1) loop under spinlock in isr
stack. If we start queuing many commands then it may take a while for
this loop to break. Though I am not quite familiar with the driver yet.

If we set CARM_MAX_Q to 30 then the request/response queue length should
also be increased right?

3)  Next I will put PCI-X analyzer and figure  out the root cause of
performance loss. May be need to get hold of the technical manual.

Kallol

On Sun, 2005-06-12 at 09:30, Mark Lord wrote:
> kallol@nucleodyne.com wrote:
> > 
> > 
> > Hello Jeff,
> >            How did you verify that performance improved making the
> > changes those
> > you suggested?
> > 
> > hdparm does not show it.
> 
> My hdparm tool performs a single I/O at a time,
> disregarding any kernel read-ahead that may be added on.
> 
> As such, it won't often show the effects of queued commands
> as well as some other test might.
> 
> Cheers
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2005-06-12 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-11  6:18 Fwd: Re: Performance figure for sx8 driver kallol
2005-06-12 16:30 ` Mark Lord
2005-06-12 17:43   ` Kallol Biswas [this message]
2005-06-13  3:39     ` Jeff Garzik
2005-06-27  1:11       ` Enabling MSI on SATAII150 Kallol Biswas
2005-06-27  3:54         ` Jeff Garzik
2005-08-20  6:19         ` Jeff Garzik

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=1118598197.25250.20.camel@driver \
    --to=kallol@nucleodyne.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --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.