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

[Mikulas Patocka]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/