From: hare@suse.de (Hannes Reinecke) Subject: RCU-ified dm-mpath for testing/review Date: Mon, 15 Feb 2016 07:47:35 +0100 [thread overview] Message-ID: <56C17487.7050301@suse.de> (raw) In-Reply-To: <20160212180032.GA14013@redhat.com> On 02/12/2016 07:00 PM, Mike Snitzer wrote: > On Fri, Feb 12 2016 at 11:04am -0500, > Hannes Reinecke <hare@suse.de> wrote: > >> On 02/12/2016 04:26 PM, Mike Snitzer wrote: >>> On Fri, Feb 12 2016 at 10:18am -0500, >>> Hannes Reinecke <hare@suse.de> wrote: >>>>> >>>> Good news is that I've managed to hit the roof for my array with the >>>> devel2 version of those patches. (And a _heavily_ patched-up lpfc >>>> driver :-) >>>> So from that perspective everything's fine now; we've reached the >>>> hardware limit for my setup. >>>> Which in itself is quite impressive; beating Intel P3700 with 16FC >>>> is not bad methinks :-) >>>> >>>> So thanks for all your work here. >>> >>> Ah, that's really good news! But devel2 is definitely _not_ destined >>> for upstream. 'devel3' is much closer to "ready". But your testing and >>> review would really push it forward. >>> >>> Please see/test: >>> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=devel3 >>> >>> Also, please read this header: >>> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=devel3&id=65a01b76502dd68e8ca298ee6614c0151b677f4a >>> >>> Even with devel2 I hacked it such that repeat_count > 1 is effectively >>> broken. I'm now _seriously_ considering deprecating repeat_count >>> completely (adding a DMWARN that will inform the user. e.g.: >>> "repeat_count > 1 is no longer supported"). I see no point going to >>> great lengths to maintain a dm-mpath feature that was only a hack for >>> when dm-mpath was bio-based. What do you think? >> >> Drop it, and make setting of which a no-op. >> Never liked it anyway, and these decisions should really be >> delegated to the path selector. > > Sure, but my point is DM-mpath will no longer be able to provide the > ability to properly handle repeat_count > 1 (because updating the > ->current_pgpath crushes the write-side of the RCU). > Fully understood. But as I said, the _need_ for repeat_count has essentially vanished with the move to request-based multipath. > As such I've rebased 'devel3' to impose repeat_count = 1 (both in > dm-mpath.c and the defaults in each path selector). Kewl. I'll give it a go. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare at suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N?rnberg)
WARNING: multiple messages have this Message-ID (diff)
From: Hannes Reinecke <hare@suse.de> To: Mike Snitzer <snitzer@redhat.com> Cc: "axboe@kernel.dk" <axboe@kernel.dk>, "keith.busch@intel.com" <keith.busch@intel.com>, Christoph Hellwig <hch@infradead.org>, Sagi Grimberg <sagig@dev.mellanox.co.il>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, device-mapper development <dm-devel@redhat.com>, Bart Van Assche <bart.vanassche@sandisk.com> Subject: Re: RCU-ified dm-mpath for testing/review Date: Mon, 15 Feb 2016 07:47:35 +0100 [thread overview] Message-ID: <56C17487.7050301@suse.de> (raw) In-Reply-To: <20160212180032.GA14013@redhat.com> On 02/12/2016 07:00 PM, Mike Snitzer wrote: > On Fri, Feb 12 2016 at 11:04am -0500, > Hannes Reinecke <hare@suse.de> wrote: > >> On 02/12/2016 04:26 PM, Mike Snitzer wrote: >>> On Fri, Feb 12 2016 at 10:18am -0500, >>> Hannes Reinecke <hare@suse.de> wrote: >>>>> >>>> Good news is that I've managed to hit the roof for my array with the >>>> devel2 version of those patches. (And a _heavily_ patched-up lpfc >>>> driver :-) >>>> So from that perspective everything's fine now; we've reached the >>>> hardware limit for my setup. >>>> Which in itself is quite impressive; beating Intel P3700 with 16FC >>>> is not bad methinks :-) >>>> >>>> So thanks for all your work here. >>> >>> Ah, that's really good news! But devel2 is definitely _not_ destined >>> for upstream. 'devel3' is much closer to "ready". But your testing and >>> review would really push it forward. >>> >>> Please see/test: >>> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=devel3 >>> >>> Also, please read this header: >>> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=devel3&id=65a01b76502dd68e8ca298ee6614c0151b677f4a >>> >>> Even with devel2 I hacked it such that repeat_count > 1 is effectively >>> broken. I'm now _seriously_ considering deprecating repeat_count >>> completely (adding a DMWARN that will inform the user. e.g.: >>> "repeat_count > 1 is no longer supported"). I see no point going to >>> great lengths to maintain a dm-mpath feature that was only a hack for >>> when dm-mpath was bio-based. What do you think? >> >> Drop it, and make setting of which a no-op. >> Never liked it anyway, and these decisions should really be >> delegated to the path selector. > > Sure, but my point is DM-mpath will no longer be able to provide the > ability to properly handle repeat_count > 1 (because updating the > ->current_pgpath crushes the write-side of the RCU). > Fully understood. But as I said, the _need_ for repeat_count has essentially vanished with the move to request-based multipath. > As such I've rebased 'devel3' to impose repeat_count = 1 (both in > dm-mpath.c and the defaults in each path selector). Kewl. I'll give it a go. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2016-02-15 6:47 UTC|newest] Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-18 12:04 dm-multipath low performance with blk-mq Sagi Grimberg 2016-01-19 10:37 ` Sagi Grimberg 2016-01-19 22:45 ` Mike Snitzer 2016-01-19 22:45 ` Mike Snitzer 2016-01-25 21:40 ` Mike Snitzer 2016-01-25 21:40 ` Mike Snitzer 2016-01-25 23:37 ` [dm-devel] " Benjamin Marzinski 2016-01-25 23:37 ` Benjamin Marzinski 2016-01-26 13:29 ` Mike Snitzer 2016-01-26 13:29 ` Mike Snitzer 2016-01-26 14:01 ` Hannes Reinecke 2016-01-26 14:47 ` Mike Snitzer 2016-01-26 14:47 ` Mike Snitzer 2016-01-26 14:56 ` Christoph Hellwig 2016-01-26 14:56 ` Christoph Hellwig 2016-01-26 15:27 ` Mike Snitzer 2016-01-26 15:27 ` Mike Snitzer 2016-01-26 15:57 ` Benjamin Marzinski 2016-01-27 11:14 ` Sagi Grimberg 2016-01-27 11:14 ` Sagi Grimberg 2016-01-27 17:48 ` Mike Snitzer 2016-01-27 17:48 ` Mike Snitzer 2016-01-27 17:51 ` Jens Axboe 2016-01-27 17:51 ` Jens Axboe 2016-01-27 18:16 ` Mike Snitzer 2016-01-27 18:16 ` Mike Snitzer 2016-01-27 18:26 ` Jens Axboe 2016-01-27 18:26 ` Jens Axboe 2016-01-27 19:14 ` Mike Snitzer 2016-01-27 19:14 ` Mike Snitzer 2016-01-27 19:50 ` Jens Axboe 2016-01-27 19:50 ` Jens Axboe 2016-01-27 17:56 ` Sagi Grimberg 2016-01-27 17:56 ` Sagi Grimberg 2016-01-27 18:42 ` Mike Snitzer 2016-01-27 18:42 ` Mike Snitzer 2016-01-27 19:49 ` Jens Axboe 2016-01-27 19:49 ` Jens Axboe 2016-01-27 20:45 ` Mike Snitzer 2016-01-27 20:45 ` Mike Snitzer 2016-01-29 23:35 ` Mike Snitzer 2016-01-29 23:35 ` Mike Snitzer 2016-01-30 8:52 ` Hannes Reinecke 2016-01-30 8:52 ` Hannes Reinecke 2016-01-30 19:12 ` Mike Snitzer 2016-01-30 19:12 ` Mike Snitzer 2016-02-01 6:46 ` Hannes Reinecke 2016-02-01 6:46 ` Hannes Reinecke 2016-02-03 18:04 ` Mike Snitzer 2016-02-03 18:04 ` Mike Snitzer 2016-02-03 18:24 ` Mike Snitzer 2016-02-03 18:24 ` Mike Snitzer 2016-02-03 19:22 ` Mike Snitzer 2016-02-03 19:22 ` Mike Snitzer 2016-02-04 6:54 ` Hannes Reinecke 2016-02-04 6:54 ` Hannes Reinecke 2016-02-04 13:54 ` Mike Snitzer 2016-02-04 13:54 ` Mike Snitzer 2016-02-04 13:58 ` Hannes Reinecke 2016-02-04 13:58 ` Hannes Reinecke 2016-02-04 14:09 ` Mike Snitzer 2016-02-04 14:09 ` Mike Snitzer 2016-02-04 14:32 ` Hannes Reinecke 2016-02-04 14:32 ` Hannes Reinecke 2016-02-04 14:44 ` Mike Snitzer 2016-02-04 14:44 ` Mike Snitzer 2016-02-05 15:13 ` [RFC PATCH] dm: fix excessive dm-mq context switching Mike Snitzer 2016-02-05 15:13 ` Mike Snitzer 2016-02-05 18:05 ` Mike Snitzer 2016-02-05 18:05 ` Mike Snitzer 2016-02-05 19:19 ` Mike Snitzer 2016-02-05 19:19 ` Mike Snitzer 2016-02-07 15:41 ` Sagi Grimberg 2016-02-07 15:41 ` Sagi Grimberg 2016-02-07 16:07 ` Mike Snitzer 2016-02-07 16:07 ` Mike Snitzer 2016-02-07 16:42 ` Sagi Grimberg 2016-02-07 16:42 ` Sagi Grimberg 2016-02-07 16:37 ` Bart Van Assche 2016-02-07 16:37 ` Bart Van Assche 2016-02-07 16:43 ` Sagi Grimberg 2016-02-07 16:43 ` Sagi Grimberg 2016-02-07 16:53 ` Mike Snitzer 2016-02-07 16:53 ` Mike Snitzer 2016-02-07 16:54 ` Sagi Grimberg 2016-02-07 16:54 ` Sagi Grimberg 2016-02-07 17:20 ` Mike Snitzer 2016-02-07 17:20 ` Mike Snitzer 2016-02-08 12:21 ` Sagi Grimberg 2016-02-08 12:21 ` Sagi Grimberg 2016-02-08 14:34 ` Mike Snitzer 2016-02-08 14:34 ` Mike Snitzer 2016-02-09 7:50 ` Hannes Reinecke 2016-02-09 7:50 ` Hannes Reinecke 2016-02-09 14:55 ` Mike Snitzer 2016-02-09 14:55 ` Mike Snitzer 2016-02-09 15:32 ` Hannes Reinecke 2016-02-09 15:32 ` Hannes Reinecke 2016-02-10 0:45 ` Mike Snitzer 2016-02-10 0:45 ` Mike Snitzer 2016-02-11 1:50 ` RCU-ified dm-mpath for testing/review Mike Snitzer 2016-02-11 3:35 ` Mike Snitzer 2016-02-11 3:35 ` Mike Snitzer 2016-02-11 15:34 ` Mike Snitzer 2016-02-11 15:34 ` Mike Snitzer 2016-02-12 15:18 ` Hannes Reinecke 2016-02-12 15:18 ` Hannes Reinecke 2016-02-12 15:26 ` Mike Snitzer 2016-02-12 15:26 ` Mike Snitzer 2016-02-12 16:04 ` Hannes Reinecke 2016-02-12 16:04 ` Hannes Reinecke 2016-02-12 18:00 ` Mike Snitzer 2016-02-12 18:00 ` Mike Snitzer 2016-02-15 6:47 ` Hannes Reinecke [this message] 2016-02-15 6:47 ` Hannes Reinecke 2016-01-26 1:49 ` [dm-devel] dm-multipath low performance with blk-mq Benjamin Marzinski 2016-01-26 1:49 ` Benjamin Marzinski 2016-01-26 16:03 ` Mike Snitzer 2016-01-26 16:03 ` Mike Snitzer 2016-01-26 16:44 ` Christoph Hellwig 2016-01-26 16:44 ` Christoph Hellwig 2016-01-27 2:09 ` Mike Snitzer 2016-01-27 2:09 ` Mike Snitzer 2016-01-27 11:10 ` Sagi Grimberg 2016-01-27 11:10 ` Sagi Grimberg 2016-01-26 21:40 ` [dm-devel] " Benjamin Marzinski 2016-01-26 21:40 ` Benjamin Marzinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=56C17487.7050301@suse.de \ --to=hare@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.