From: Mike Fedyk <mfedyk@matchmail.com>
To: Mark Peloquin <peloquin@us.ibm.com>
Cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org
Subject: Re: Bio pool & scsi scatter gather pool usage
Date: Thu, 25 Apr 2002 12:43:46 -0700 [thread overview]
Message-ID: <20020425194346.GN574@matchmail.com> (raw)
In-Reply-To: <OFA8584441.22F71259-ON85256B9F.00627FAA@pok.ibm.com>
On Thu, Apr 18, 2002 at 01:23:47PM -0500, Mark Peloquin wrote:
>
> > Andrew Morton wrote:
> > >
> > > Mark Peloquin wrote:
> > > >
> > > ...
> > > > In EVMS, we are adding code to deal with BIO splitting, to
> > > > enable our feature modules, such as DriveLinking, LVM, & MD
> > > > Linear, etc to break large BIOs up on chunk size or lower
> > > > level device boundaries.
> > >
> > > Could I suggest that this code not be part of EVMS, but that
> > > you implement it as a library within the core kernel? Lots of
> > > stuff is going to need BIO splitting - software RAID, ataraid,
> > > XFS, etc. May as well talk with Jens, Martin Petersen, Arjan,
> > > Neil Brown. Do it once, do it right...
> > >
> > I take that back.
> >
> > We really, really do not want to perform BIO splitting at all.
> > It requires that the kernel perform GFP_NOIO allocations at
> > the worst possible time, and it's just broken.
> >
> > What I would much prefer is that the top-level BIO assembly
> > code be able to find out, beforehand, what the maximum
> > permissible BIO size is at the chosen offset. It can then
> > simple restrict the BIO to that size.
> >
> > Simply:
> >
> > max = bio_max_bytes(dev, block);
> >
> > which gets passed down the exact path as the requests themselves.
> > Each layer does:
> >
> > int foo_max_bytes(sector_t sector)
> > {
> > int my_maxbytes, his_maxbytes;
> > sector_t my_sector;
> >
> > my_sector = my_translation(sector);
> > his_maxbytes = next_device(me)->max_bytes(my_sector);
> > my_maxbytes = whatever(my_sector);
> > return min(my_maxbytes, his_maxbytes);
> > }
> >
> > and, at the bottom:
> >
> > int ide_max_bytes(sector_t sector)
> > {
> > return 248 * 512;
> > }
> >
> > BIO_MAX_SECTORS and request_queue.max_sectors go away.
> >
> > Tell me why this won't work?
>
> This would require the BIO assembly code to make at least one
> call to find the current permissible BIO size at offset xyzzy.
> Depending on the actual IO size many foo_max_bytes calls may
> be required. Envision the LVM or RAID case where physical
> extents or chunks sizes can be as small as 8Kb I believe. For
> a 64Kb IO, its conceivable that 9 calls to foo_max_bytes may
> be required to package that IO into permissibly sized BIOs.
>
> What your proposing is doable, but not without a cost.
Why not just put the smallest required BIO size in a struct for that device?
Then each read of that struct can be kept in cache...
Is the BIO max size going to change at different offsets?
next prev parent reply other threads:[~2002-04-25 19:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 18:23 Bio pool & scsi scatter gather pool usage Mark Peloquin
2002-04-18 18:57 ` Andrew Morton
2002-04-19 15:44 ` Denis Vlasenko
2002-04-25 19:43 ` Mike Fedyk [this message]
2002-04-25 19:56 ` Andrew Morton
2002-04-25 19:59 ` David Mansfield
-- strict thread matches above, loose matches on Subject: below --
2002-04-18 23:11 Douglas Gilbert
2002-04-18 22:58 Mark Peloquin
2002-04-18 23:36 ` Alan Cox
2002-04-18 23:48 ` Andrew Morton
2002-04-19 7:29 ` Stephen Lord
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
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=20020425194346.GN574@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=akpm@zip.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox