Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Miller <davem@...>
Cc: <mpatocka@...>, <fujita.tomonori@...>, <jens.axboe@...>, <linux-kernel@...>, <linux-scsi@...>, <linux-parisc@...>
Date: Sunday, July 20, 2008 - 10:52 am

On Sat, 2008-07-19 at 21:07 -0700, David Miller wrote:

You can ... as soon as BIO_VMERGE_BOUNDARY is undefined or set to zero,
it gets compiled out of the block code. 

Since we're using it successfully in parisc, I don't want the block code
removed, but I don't see a reason to force other architectures to use
it.

However, it has two use cases.  One is the legacy one of making rather
dumb I/O cards perform better (which is the primary on on parisc), but
there is a current one making huge transfers go through SCSI using using
the sg_table code.  That latter is pretty vital to me since I have to
keep the code working, but I don't really have any SCSI cards that can
take advantage of it without virtual merging.  As a slight irony, IBM is
trying to persuade me that a ppc would be better than a parisc for big
endian I/O testing ... so I might just be seeing if I can make virtual
merging work on power too.

James


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] block: fix q->max_segment_size checking in bl..., James Bottomley, (Sun Jul 20, 10:52 am)
Re: [PATCH] block: fix q-&gt;max_segment_size checking in bl..., John David Anglin, (Thu Jul 24, 10:40 pm)