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

[Mikulas Patocka <mpatocka@redhat.com>]

On Tue, 15 Jul 2008, James Bottomley wrote:

> On Tue, 2008-07-15 at 11:58 -0400, Mikulas Patocka wrote:
>> You are mixing two ideas here:
>>
>> (1) virtual merging --- IOMMU maps discontinuous segments into continuous
>> area that it presents to the device.
>>
>> (2) virtual merge accounting --- block layer tries to guess how many
>> segments will be created by (1) and merges small requests into big ones.
>> The resulting requests are as big that they can't be processed by the
>> device if (1) weren't in effect.
>
> No ... I'm not ... the virtual merge implementation requires the block
> layer to get this accounting right, otherwise the iommu code can end up
> doing the wrong thing.

The virtual merge (1) can work even without accounting (2). IOMMU can 
always create less sg entries then the block layer expects.

> You're proposing to eliminate the difference between max_phys_segments
> and max_hw_segments without actually removing them.

Yes. Only for alpha and pa-risc, there is difference between these values. 
And both of these architectures are being discontinued.

>> That's why I'm proposing to remove virtual merge accounting (2), but leave
>> virtual merging (1) itself. The accounting doesn't reduce number of sg
>> slots.
>
> Yes, but it's gains very little ... architectures that don't want it can
> already turn it off, and it's useful for those, like parisc, who do.
>
> James

It increases maintainability of the code, reduces bloat and bugs.

Mikulas