public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: Bio pool & scsi scatter gather pool usage
Date: Wed, 24 Apr 2002 12:20:08 +0200	[thread overview]
Message-ID: <3CC686D8.44435CE5@aitel.hist.no> (raw)
In-Reply-To: <E16yUE0-0006i7-00@the-village.bc.nu>

Alan Cox wrote:
> 
> > 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.
> 
> Its still cheaper to merge bio chains than split them. The VM issues with
> splitting them are not nice at all since you may need to split a bio to
> write out a page and it may be the last page

How about reserving a small memory pool for splitting when normal
memory allocation fails?  

I know we want a clean kernel,
so this mechanism would be implemented in those drivers that
actually need it.  I.e. raid0/5 would keep a
emergency split buffer around for bio's bigger than the
stripe size, devices with all sorts of odd requirement could do the
same.
This might look like duplication, but isn't really as the different
devices
might need different splitting anyway.  I.e. RAID want to
split into stripe-sized chunks but no smaller, an odd device might
need something different.  The disk concatenation in md would
only want to split when you actually hit a boundary.
Also, letting each driver handle the special cases itself
works when someone makes raid-0 on top
of weird adapters.

A kernel with just plain disk drivers wouldn't need
and wouldn't have such mechanisms either.

Helge Hafting

  parent reply	other threads:[~2002-04-24 10:20 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
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 [this message]
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=3CC686D8.44435CE5@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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