Re: allowed pages in the block later, was Re: [Ext2-devel] [PATCH]ext3: avoid sending down non-refcounted pages

[Mike Christie]

Mike Christie wrote:
> Christoph Hellwig wrote:
>
> > On Thu, Dec 08, 2005 at 03:18:33AM -0700, Andreas Dilger wrote:
> >
> > > What happens on 1kB or 2kB block filesystems (i.e. b_size != PAGE_SIZE)?
> > > This will allocate a whole page for each block (which may be 
> > > considerable
> > > overhead on e.g. a 64kB PAGE_SIZE ia64 or PPC system).
> >
> >
> >
> > Yes.  How often do we trigger this codepath?
> >
> > The problem we're trying to solve here is how do implement network block
> > devices (nbd, iscsi) efficiently.  The zero copy codepath in the 
> > networking
> > layer does need to grab additional references to pages.  So to use 
> > sendpage
> > we need a refcountable page.  pages used by the slab allocator are not
> > normally refcounted so try to do get_page/pub_page on them will break.
> >
> > One way to work around that would be to detect kmalloced pages and use
> > a slowpath for that.  The major issues with that is that we don't have a
> > reliable way to detect if a given struct page comes from the slab 
> > allocator
> > or not.  The minor problem is that even with such an indicator it means
> > having a separate and lightly tested slowpath for this rare case.
> >
> > All in all I think we should document that the block layer only accepts
> > properly refcounted pages, which is everything but kmalloced pages (even
> > vmalloc is totally fine)
>
>
> Is it anytime kmalloc is used? For scsi when it uses scsi_execute* for 
> something like scanning (report luns result is kmallocd) would this be a 
> problem?
>
> If PageSlab() does work, then could we have a request queue flag that 
> bounces those pages for all block layer drivers. Pretty slow and yucky 
> but if we have to convert SCSI and maybe other parts of the block layer 
> maybe it will be easiest for now.

Or there is not a way to do kmalloc(GFP_BLK) that gives us the right 
type of memory is there?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/