public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Corry <kevcorry@us.ibm.com>
To: Jens Axboe <axboe@suse.de>
Cc: Adrian Bunk <bunk@stusta.de>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: 2.6: drivers/md/dm-io.c partially copies bio.c
Date: Mon, 6 Dec 2004 08:22:18 -0600	[thread overview]
Message-ID: <200412060822.18688.kevcorry@us.ibm.com> (raw)
In-Reply-To: <20041206135539.GZ10498@suse.de>

On Monday 06 December 2004 7:55 am, Jens Axboe wrote:
> On Mon, Dec 06 2004, Kevin Corry wrote:
> > Hi Adrian,
> >
> > On Monday 06 December 2004 6:09 am, Adrian Bunk wrote:
> > > drivers/md/dm-io.c copies functionality from bio.c .
> > >
> > > Is there a specific reason why you don't simply use the functionality
> > > bio.c provides?
> >
> > Can you give some specific examples of the functionality you think is
> > duplicated? Meanwhile, I'll take a look and see if I can explain any code
> > overlaps.
>
> Ah come on Kevin, a 2 second glance shows lots of uneccesary
> duplication. Basically only the concept of the bio_set is not duplicated
> in the first many lines, you even set up matching slabs.
>
> How was that ever accepted for merging?

If I recall correctly (and it's been a while since I've looked at that code), 
the bio_set was added because a few DM modules like to initiate their own I/O 
requests (things like snapshots and DM's kcopyd daemon), and we felt it was 
better to allow these modules to each create their own mempools to allocate 
bios from, rather than allocate from the single kernel-wide bio pool used by 
the filesystem layer.

Strictly speaking (and as you mentioned), the slabs in the bio_set are 
unnecessary, and they could use the global bio_slab. But there's probably 
some argument to be made for having separate bio mempools for these modules.

Actually, I also seem to recall discussions with Joe Thornber from quite 
awhile ago about trying to move this bio_set functionality into fs/bio.c, to 
allow other device drivers to create their own private bio pools. If you 
think something like this would be desireable, I can try to look into the 
specifics again. If you think that having the single kernel-wide bio pool is 
sufficient for all filesystems and device-drivers (you certainly understand 
the trade-offs better than I do), then I can look into removing the necessary 
code from dm-io.c

-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/

  reply	other threads:[~2004-12-06 14:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-06 12:09 2.6: drivers/md/dm-io.c partially copies bio.c Adrian Bunk
2004-12-06 13:48 ` Kevin Corry
2004-12-06 13:55   ` Jens Axboe
2004-12-06 14:22     ` Kevin Corry [this message]
2004-12-06 14:42       ` Jens Axboe
2004-12-08 13:51         ` Kevin Corry
2004-12-08 14:31       ` [dm-devel] " Alasdair G Kergon

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=200412060822.18688.kevcorry@us.ibm.com \
    --to=kevcorry@us.ibm.com \
    --cc=axboe@suse.de \
    --cc=bunk@stusta.de \
    --cc=dm-devel@redhat.com \
    --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