Re: [PATCH 0/5] convert sg to use the block layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 26 Aug 2008 09:56:28 +0200
Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:

> On Tue, Aug 26 2008, FUJITA Tomonori wrote:
> > This patchset converts sg to use the block layer functions. That is,
> > sg doesn't use scsi_execute_async() any more. This is a part of the
> > overdue task to remove scsi_req_map_sg.
> > 
> > I tested this patchset with sg v3 and the old interface (struct
> > sg_header) via SG_IO (v3) and the vfs API.
> > 
> > 
> > Doug,
> > 
> > 1. I don't demote the sg driver's GFP_ATOMIC to GFP_KERNEL. sg always
> > uses GFP_ATOMIC as before.
> > 
> > 2. I don't remove GFP_DMA allocation. As before, sg allocates reserved
> > pages with GFP_DMA (sfp->low_dma case).
> > 
> > 3. I keep the reserved buffer per struct sg_fd as before.
> > 
> > 4. I use high-order page allocation for reserved buffer as before. sg
> > works well with HBAs that have the limitation of the number of sg
> > entries.
> > 
> > 5. I think that you were concern about the overhead of the block layer
> > functions. But if you look at scsi_execute_async() that sg uses now,
> > you can find that scsi_execute_async() uses the block layer functions
> > internally. So the current sg incurs the overhead (if such overhead
> > exists).
> > 
> > 
> > Jens,
> > 
> > I keep the block API changes to a minimum (I might need more changes
> > for st/osst but I'd like to progress step by step). I did only two
> > things.
> > 
> > 1. I add gfp_mask argument to blk_rq_map_user and blk_rq_map_user_iov.
> > 
> > 2. I introduces struct rq_map_data holding pages. sg puts
> > pre-allocated pages to it and passes it to bio_copy_user_iov(). The
> > current users of bio_copy_user_iov simply passes NULL. blk_rq_map_user
> > and blk_rq_map_user_iov take a pointer to struct rq_map_data and in
> > the end bio_copy_user_iov gets it.
> > 
> > 
> > This patchset against the for-linus branch in Jens' tree + the two
> > patches for 2.6.27:
> > 
> > http://marc.info/?l=linux-kernel&m=121964251911717&w=2
> > http://marc.info/?l=linux-kernel&m=121964241911611&w=2
> > 
> > After Jens rebases the for-2.6.28 brach, I'll update this patchset
> > too.
> 
> Thanks a lot for doing this work, it's been pending for a long time.
> I've rebased for-2.6.28 on top of for-linus to ease this integration, so
> if you could resend the patchset then I can add it.

Thanks, I put an updated version against the for-2.6.28 branch in your
tree:

git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git sg-block


Can you wait for a little while before applying this to your
for-2.6.28 branch? We need Doug's ACK on this.

But I think that it's nice if you can send this to linux-next since
testing this patchset on linux-next is good.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux