lkml.org 
[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE
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


\
 
 \ /
  Last update: 2008-07-15 18:25    [W:0.136 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site