Messages in this thread | | | Date | Mon, 24 Apr 2006 11:05:08 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] Direct I/O bio size regression |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |