Messages in this thread | | | Date | Thu, 24 Jul 2008 12:34:31 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE |
| |
On Thu, 24 Jul 2008, James Bottomley wrote:
> On Thu, 2008-07-24 at 11:07 -0400, Mikulas Patocka wrote: > > So try to #define BIO_VMERGE_BOUNDARY 0 for Pa-Risc and tell us what > > performance degradation do you see (and what driver do you use and what is > > the I/O pattern). > > > > If you show something specific, we can consider that --- but you haven't > > yet told us anything, except generic talk. > > You keep ignoring inconvenient facts. For about the third time: > > I run a test bed for sg_tables (large chaining of requests). This runs > on parisc using virtual merging (has to because the final physical table > size can't go over the sg list of the SCSI card). If I turn off virtual > merging I can no longer test sg_tables in vanilla kernels. > > James
What sg_tables test do you mean? What does the test do? Why couldn't you run the test if BIO_VMERGE_BOUNDARY is 0? Normal I/O obviously can work with BIO_VMERGE_BOUNDARY 0, the kernel will just send more smaller requests.
Mikulas
| |