Messages in this thread | | | Date | Tue, 15 Jul 2008 12:20:59 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: [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
| |