public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: scameron@beardog.cca.cpqcorp.net, linux-kernel@vger.kernel.org,
	mike.miller@hp.com, akpm@linux-foundation.org,
	linux-scsi@vger.kernel.org, coldwell@redhat.com, hare@novell.com,
	iss_storagedev@hp.com
Subject: Re: [PATCH] hpsa: SCSI driver for HP Smart Array controllers
Date: Fri, 6 Mar 2009 10:35:21 +0100	[thread overview]
Message-ID: <20090306093520.GV11787@kernel.dk> (raw)
In-Reply-To: <20090306182705P.fujita.tomonori@lab.ntt.co.jp>

On Fri, Mar 06 2009, FUJITA Tomonori wrote:
> On Fri, 6 Mar 2009 10:21:14 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Fri, Mar 06 2009, FUJITA Tomonori wrote:
> > > On Fri, 6 Mar 2009 09:55:29 +0100
> > > Jens Axboe <jens.axboe@oracle.com> wrote:
> > > 
> > > > > If it's settable at init time, that would probably be enough for
> > > > > the vast majority of uses (and more flexible than what we have now)
> > > > > and a lot easier to implement.
> > > > 
> > > > Completely agree, don't waste time implementing something that nobody
> > > > will ever touch. The only reason to fiddle with such a setting would be
> > > > to increase it, because ios are too small. And even finding out that the
> > > > segment limit is the one killing you would take some insight and work
> > > > from the user.
> > > > 
> > > > Just make it Big Enough to cover most cases. 32 is definitely small, 256
> > > > entries would get you 1MB ios which I guess is more appropriate.
> > > 
> > > I guess that the dynamic scheme is overdoing but seems that vendors
> > > like some way to configure the sg entry size. The new MPT2SAS driver
> > > has SCSI_MPT2SAS_MAX_SGE kernel config option:
> > > 
> > > http://marc.info/?l=linux-scsi&m=123619290803547&w=2
> > > 
> > > 
> > > The kernel module option for this might be appropriate.
> > 
> > Dunno, still seems pretty pointless to me. The config option there
> > quotes memory consumption as the reason to reduce the number of sg
> > entries, however I think that's pretty silly. Additionally, a kernel
> > config entry just means that customers will be stuck with a fixed value
> > anyway. So I just don't see any merit to doing it that way either.
> 
> Yeah, agreed. the kernel config option is pretty pointless. But I'm
> not sure that reducing memory consumption is completely pointless.

Agree, depends on how you do it. If you preallocate all the memory
required for 1024 entries times the queue depth, then it may not be that
small. But you can do it a bit more cleverly than that, and then I don't
think it makes a lot of sense to provide any options for shrinking it.

-- 
Jens Axboe


  reply	other threads:[~2009-03-06  9:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-02 14:56 [PATCH] hpsa: SCSI driver for HP Smart Array controllers scameron
2009-03-03  6:35 ` FUJITA Tomonori
2009-03-03 16:28   ` scameron
2009-03-05  5:48     ` FUJITA Tomonori
2009-03-05 14:21       ` scameron
2009-03-05 16:54         ` Andrew Patterson
2009-03-06  8:55         ` Jens Axboe
2009-03-06  9:13           ` FUJITA Tomonori
2009-03-06  9:21             ` Jens Axboe
2009-03-06  9:27               ` FUJITA Tomonori
2009-03-06  9:35                 ` Jens Axboe [this message]
2009-03-06 14:38                   ` scameron
2009-03-06 19:06                     ` Jens Axboe
2009-03-06 20:59                     ` Grant Grundler
2009-03-06 21:18                       ` scameron
2009-03-06 21:55                         ` Grant Grundler
2009-03-06 21:59                         ` James Bottomley
2009-03-05 14:55       ` Miller, Mike (OS Dev)
2009-03-03 16:49 ` Mike Christie
2009-03-03 21:28   ` scameron
  -- strict thread matches above, loose matches on Subject: below --
2009-02-27 23:09 Mike Miller
2009-03-01 13:49 ` Rolf Eike Beer
2009-03-02  6:32 ` FUJITA Tomonori
2009-03-02 17:19   ` Grant Grundler
2009-03-02 18:20     ` Mike Christie
2009-03-02 18:36       ` Jens Axboe
2009-03-02 20:33         ` Mike Christie
2009-03-02 20:37           ` Mike Christie
2009-03-03  9:43           ` Jens Axboe

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=20090306093520.GV11787@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=coldwell@redhat.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hare@novell.com \
    --cc=iss_storagedev@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mike.miller@hp.com \
    --cc=scameron@beardog.cca.cpqcorp.net \
    /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