Re: [PATCH] Direct I/O bio size regression

[Jens Axboe]

On Mon, Apr 24 2006, Jens Axboe wrote:
> > Index: 2.6.x-xfs-new/fs/bio.c
> > ===================================================================
> > --- 2.6.x-xfs-new.orig/fs/bio.c	2006-02-06 11:57:50.000000000 +1100
> > +++ 2.6.x-xfs-new/fs/bio.c	2006-04-24 15:46:16.849484424 +1000
> > @@ -304,7 +304,7 @@ int bio_get_nr_vecs(struct block_device 
> >  	request_queue_t *q = bdev_get_queue(bdev);
> >  	int nr_pages;
> >  
> > -	nr_pages = ((q->max_sectors << 9) + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > +	nr_pages = ((q->max_hw_sectors << 9) + PAGE_SIZE - 1) >> PAGE_SHIFT;
> >  	if (nr_pages > q->max_phys_segments)
> >  		nr_pages = q->max_phys_segments;
> >  	if (nr_pages > q->max_hw_segments)
> > @@ -446,7 +446,7 @@ int bio_add_page(struct bio *bio, struct
> >  		 unsigned int offset)
> >  {
> >  	struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> > -	return __bio_add_page(q, bio, page, len, offset, q->max_sectors);
> > +	return __bio_add_page(q, bio, page, len, offset, q->max_hw_sectors);
> >  }
> >  
> >  struct bio_map_data {
> 
> Clearly correct, I'll make sure this gets merged right away.

Spoke too soon... The last part is actually on purpose, to prevent
really huge requests as part of normal file system IO. That's why we
have a bio_add_pc_page(). The first hunk may cause things to not work
optimally then if we don't apply the last hunk.

The best approach is probably to tune max_sectors on the system itself.
That's why it is exposed, after all.

-- 
Jens Axboe

-
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/