All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Lord <lord@sgi.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Mark Peloquin <peloquin@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Bio pool & scsi scatter gather pool usage
Date: Fri, 19 Apr 2002 02:29:25 -0500	[thread overview]
Message-ID: <3CBFC755.50106@sgi.com> (raw)
In-Reply-To: <OFCF00F1A4.2665039D-ON85256B9F.006B755C@pok.ibm.com> from "Mark Peloquin" at Apr 18, 2002 05:58:16 PM <E16yLS4-0005vN-00@the-village.bc.nu> <3CBF5B67.E488A8E5@zip.com.au>

Andrew Morton wrote:

>Alan Cox wrote:
>
>>>Perhaps, but calls are expensive. Repeated calls down stacked block
>>>devices will add up. In only the most unusually cases will there
>>>
>>You don't need to repeatedly query. At bind time you can compute the
>>limit for any device heirarchy and be done with it.
>>
>
>S'pose so.  The ideal request size is variable, based
>on the alignment.  So for exampe if the start block is
>halfway into a stripe, the ideal BIO size is half a stripe.
>
>But that's a pretty simple table to generate once-off,
>as you say.
>

But this gets you lowest common denominator sizes for the whole
volume, which is basically the buffer head approach, chop all I/O up
into a chunk size we know will always work. Any sort of nasty  boundary
condition at one spot in a volume means the whole thing is crippled
down to that level. It then becomes a black magic art to configure a
volume which is not restricted to a small request size.

Steve



  reply	other threads:[~2002-04-19  7:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-18 22:58 Bio pool & scsi scatter gather pool usage Mark Peloquin
2002-04-18 23:36 ` Alan Cox
2002-04-18 23:48   ` Andrew Morton
2002-04-19  7:29     ` Stephen Lord [this message]
2002-04-19  8:08       ` Joe Thornber
2002-04-19  8:51         ` Alan Cox
2002-04-19  8:58       ` Alan Cox
2002-04-19 15:27         ` Steve Lord
2002-04-19 15:57           ` Alan Cox
2002-04-19 15:51             ` Rik van Riel
2002-04-22  6:50         ` Suparna Bhattacharya
2002-04-22  7:06           ` arjan
2002-04-22  7:54             ` Suparna Bhattacharya
2002-04-24 10:20         ` Helge Hafting
2002-04-19 18:15     ` Oliver Xymoron
  -- strict thread matches above, loose matches on Subject: below --
2002-04-18 23:11 Douglas Gilbert
2002-04-18 18:23 Mark Peloquin
2002-04-18 18:57 ` Andrew Morton
2002-04-19 15:44   ` Denis Vlasenko
2002-04-25 19:43 ` Mike Fedyk
2002-04-25 19:56   ` Andrew Morton
2002-04-25 19:59   ` David Mansfield
2002-04-18 13:58 Mark Peloquin
2002-04-18 16:17 ` Andrew Morton
2002-04-18 17:35   ` Andrew Morton

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=3CBFC755.50106@sgi.com \
    --to=lord@sgi.com \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peloquin@us.ibm.com \
    /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.