RE: [PATCH 1/1] cciss: read config to obtain max outstandingcommands per controller

From: Miller, Mike (OS Dev)
Date: Mon Jul 07 2008 - 11:13:02 EST




> -----Original Message-----
> From: Andrew Morton [mailto:akpm@xxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, July 01, 2008 4:23 PM
> To: Miller, Mike (OS Dev)
> Cc: jens.axboe@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> linux-scsi@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 1/1] cciss: read config to obtain max
> outstanding commands per controller
>
> On Tue, 1 Jul 2008 16:02:47 -0500
> Mike Miller <mike.miller@xxxxxx> wrote:
>
> > This patch changes the way we determine the maximum number of
> > outstanding commands for each controller. Most Smart Array
> controllers
> > can support up to 1024 commands, the notable exceptions are
> the E200 and E200i.
> > The next generation of controllers which were just added support a
> > mode of operation called Zero Memory Raid (ZMR). In this mode they
> > only support 64 outstanding commands. In Full Function Raid
> (FFR) mode they support 1024.
> > We have been setting the queue depth by arbitrarily assigning some
> > value for each controller. We needed a better way to set the queue
> > depth to avoid lots of annoying "fifo full" messages. So we
> made the
> > driver a little smarter. We now read the config table and
> subtract 4
> > from the returned value. The -4 is to allow some room for
> ioctl calls
> > which are not tracked the same way as io commands are tracked.
>
> What would be the effect of _not_ having this patch upon
> users of the new hardware?
>
> If the answer is "bad" then we should get this change into
> 2.6.26 and 2.6.25.x, because people will surely be running
> those kernels on the new hardware.

Sorry for my late reply, I've been out of the office. Not having this patch would be bad. The performance at a queue depth of 64 is not very good anyway. If we hit the "fifo full" condition we spew annoying messages and spin for a bit and try again. This leads to very poor performance.

Thanks,
mikem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/