On Tue, Apr 19, 2011 at 5:32 AM, David Dillow <dave@xxxxxxxxxxxxxx> wrote: > > On Mon, 2011-04-18 at 20:21 +0200, Bart Van Assche wrote: > > On Mon, Apr 18, 2011 at 1:44 PM, Jens Axboe <jaxboe@xxxxxxxxxxxx> wrote: > > > Bart, can you try and pull: > > > > > > git://git.kernel.dk/linux-2.6-block.git for-linus > > > > > > into Linus' tree and see if that works? This has, among other things, > > > Neils fixes for MD. > > > > md seems to work stable with the resulting tree, but it looks there is > > a performance regression in the block layer not related to the md > > issue. If I run a small block IOPS test on a block device created by > > ib_srp (NOOP scheduler) I see about 11% less IOPS than with 2.6.38.3 > > (155.000 IOPS with 2.6.38.3 and 140.000 IOPS with 2.6.39-rc3+). > > The mapping code for ib_srp changed in 2.6.39-rc1, but it showed > improved IOPS for a similar setup in my testing so I'd be surprised if > it is the culprit. Still, it wouldn't hurt to check. Do you have time to > try the new ib_srp code with 2.6.38.3 to eliminate it from the equation? Hello Dave, I just ran a test with the most important 2.6.39-specific ib_srp commits reverted but that didn't yield a measurable performance difference for this specific test: $ git show --format=format:%s 7f9e5c48c1078507747434d4c182ab10925bf98a be8b981453a4904399cb090c1660618e250092d8 c07d424d6118d528ef71b22b7424bfc359c307a5 8f26c9ff9cd0317ad867bce972f69e0c6c2cbe3c 961e0be89a5120a1409ebc525cca6f603615a8a8 8c4037b501acd2ec3abc7925e66af8af40a2da9d | grep '^IB' IB: Increase DMA max_segment_size on Mellanox hardware IB/srp: try to use larger FMR sizes to cover our mappings IB/srp: add support for indirect tables that don't fit in SRP_CMD IB/srp: rework mapping engine to use multiple FMR entries IB/srp: move IB CM setup completion into its own function IB/srp: always avoid non-zero offsets into an FMR Bart. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
