linux-kernel - RE: [PATCH 1/1] cciss: read config to obtain max outstanding commands per controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 7 Jul 2008 15:12:19 +0000
From:	"Miller, Mike (OS Dev)" <Mike.Miller@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: [PATCH 1/1] cciss: read config to obtain max outstanding
 commands per controller



> -----Original Message-----
> From: Andrew Morton [mailto:akpm@...ux-foundation.org]
> Sent: Tuesday, July 01, 2008 4:23 PM
> To: Miller, Mike (OS Dev)
> Cc: jens.axboe@...cle.com; linux-kernel@...r.kernel.org;
> linux-scsi@...r.kernel.org
> 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@...com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/