From: Ming Lei <ming.lei@redhat.com> To: Mike Snitzer <snitzer@redhat.com> Cc: axboe@kernel.dk, martin.petersen@oracle.com, linux-block@vger.kernel.org, dm-devel@redhat.com, jdorminy@redhat.com, bjohnsto@redhat.com Subject: Re: [PATCH v2] block: use gcd() to fix chunk_sectors limit stacking Date: Fri, 4 Dec 2020 09:12:43 +0800 [thread overview] Message-ID: <20201204011243.GB661914@T590> (raw) In-Reply-To: <20201203143359.GA29261@redhat.com> On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote: > On Wed, Dec 02 2020 at 10:26pm -0500, > Ming Lei <ming.lei@redhat.com> wrote: > > > On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote: > > > commit 22ada802ede8 ("block: use lcm_not_zero() when stacking > > > chunk_sectors") broke chunk_sectors limit stacking. chunk_sectors must > > > reflect the most limited of all devices in the IO stack. > > > > > > Otherwise malformed IO may result. E.g.: prior to this fix, > > > ->chunk_sectors = lcm_not_zero(8, 128) would result in > > > blk_max_size_offset() splitting IO at 128 sectors rather than the > > > required more restrictive 8 sectors. > > > > What is the user-visible result of splitting IO at 128 sectors? > > The VDO dm target fails because it requires IO it receives to be split > as it advertised (8 sectors). OK, looks VDO's chunk_sector limit is one hard constraint, even though it is one DM device, so I guess you are talking about DM over VDO? Another reason should be that VDO doesn't use blk_queue_split(), otherwise it won't be a trouble, right? Frankly speaking, if the stacking driver/device has its own hard queue limit like normal hardware drive, the driver should be responsible for the splitting. > > > I understand it isn't related with correctness, because the underlying > > queue can split by its own chunk_sectors limit further. So is the issue > > too many further-splitting on queue with chunk_sectors 8? then CPU > > utilization is increased? Or other issue? > > No, this is all about correctness. > > Seems you're confining the definition of the possible stacking so that > the top-level device isn't allowed to have its own hard requirements on I just don't know this story, thanks for your clarification. As I mentioned above, if the stacking driver has its own hard queue limit, it should be the driver's responsibility to respect it via blk_queue_split() or whatever. Thanks, Ming
WARNING: multiple messages have this Message-ID (diff)
From: Ming Lei <ming.lei@redhat.com> To: Mike Snitzer <snitzer@redhat.com> Cc: axboe@kernel.dk, martin.petersen@oracle.com, jdorminy@redhat.com, bjohnsto@redhat.com, linux-block@vger.kernel.org, dm-devel@redhat.com Subject: Re: [dm-devel] [PATCH v2] block: use gcd() to fix chunk_sectors limit stacking Date: Fri, 4 Dec 2020 09:12:43 +0800 [thread overview] Message-ID: <20201204011243.GB661914@T590> (raw) In-Reply-To: <20201203143359.GA29261@redhat.com> On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote: > On Wed, Dec 02 2020 at 10:26pm -0500, > Ming Lei <ming.lei@redhat.com> wrote: > > > On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote: > > > commit 22ada802ede8 ("block: use lcm_not_zero() when stacking > > > chunk_sectors") broke chunk_sectors limit stacking. chunk_sectors must > > > reflect the most limited of all devices in the IO stack. > > > > > > Otherwise malformed IO may result. E.g.: prior to this fix, > > > ->chunk_sectors = lcm_not_zero(8, 128) would result in > > > blk_max_size_offset() splitting IO at 128 sectors rather than the > > > required more restrictive 8 sectors. > > > > What is the user-visible result of splitting IO at 128 sectors? > > The VDO dm target fails because it requires IO it receives to be split > as it advertised (8 sectors). OK, looks VDO's chunk_sector limit is one hard constraint, even though it is one DM device, so I guess you are talking about DM over VDO? Another reason should be that VDO doesn't use blk_queue_split(), otherwise it won't be a trouble, right? Frankly speaking, if the stacking driver/device has its own hard queue limit like normal hardware drive, the driver should be responsible for the splitting. > > > I understand it isn't related with correctness, because the underlying > > queue can split by its own chunk_sectors limit further. So is the issue > > too many further-splitting on queue with chunk_sectors 8? then CPU > > utilization is increased? Or other issue? > > No, this is all about correctness. > > Seems you're confining the definition of the possible stacking so that > the top-level device isn't allowed to have its own hard requirements on I just don't know this story, thanks for your clarification. As I mentioned above, if the stacking driver has its own hard queue limit, it should be the driver's responsibility to respect it via blk_queue_split() or whatever. Thanks, Ming -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2020-12-04 1:14 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-30 17:18 [PATCH] block: revert to using min_not_zero() when stacking chunk_sectors Mike Snitzer 2020-11-30 17:18 ` [dm-devel] " Mike Snitzer 2020-11-30 20:51 ` John Dorminy 2020-11-30 20:51 ` [dm-devel] " John Dorminy 2020-11-30 23:24 ` Mike Snitzer 2020-11-30 23:24 ` [dm-devel] " Mike Snitzer 2020-12-01 0:21 ` John Dorminy 2020-12-01 0:21 ` [dm-devel] " John Dorminy 2020-12-01 2:12 ` Mike Snitzer 2020-12-01 2:12 ` [dm-devel] " Mike Snitzer 2020-12-01 16:07 ` [PATCH v2] block: use gcd() to fix chunk_sectors limit stacking Mike Snitzer 2020-12-01 16:07 ` [dm-devel] " Mike Snitzer 2020-12-01 17:43 ` John Dorminy 2020-12-01 17:43 ` [dm-devel] " John Dorminy 2020-12-01 17:53 ` Jens Axboe 2020-12-01 17:53 ` [dm-devel] " Jens Axboe 2020-12-01 18:02 ` Martin K. Petersen 2020-12-01 18:02 ` [dm-devel] " Martin K. Petersen 2020-12-02 3:38 ` [PATCH] dm: " Jeffle Xu 2020-12-02 3:38 ` [dm-devel] " Jeffle Xu 2020-12-02 3:38 ` Jeffle Xu 2020-12-02 3:38 ` [dm-devel] " Jeffle Xu 2020-12-02 3:57 ` JeffleXu 2020-12-02 3:57 ` [dm-devel] " JeffleXu 2020-12-02 5:03 ` Mike Snitzer 2020-12-02 5:03 ` [dm-devel] " Mike Snitzer 2020-12-02 5:14 ` Mike Snitzer 2020-12-02 5:14 ` [dm-devel] " Mike Snitzer 2020-12-02 6:31 ` JeffleXu 2020-12-02 6:31 ` [dm-devel] " JeffleXu 2020-12-02 6:35 ` JeffleXu 2020-12-02 6:35 ` [dm-devel] " JeffleXu 2020-12-02 6:28 ` JeffleXu 2020-12-02 6:28 ` [dm-devel] " JeffleXu 2020-12-02 7:10 ` JeffleXu 2020-12-02 7:10 ` [dm-devel] " JeffleXu 2020-12-02 15:11 ` Mike Snitzer 2020-12-02 15:11 ` [dm-devel] " Mike Snitzer 2020-12-03 1:48 ` JeffleXu 2020-12-03 1:48 ` JeffleXu 2020-12-03 3:26 ` [PATCH v2] block: " Ming Lei 2020-12-03 3:26 ` [dm-devel] " Ming Lei 2020-12-03 14:33 ` Mike Snitzer 2020-12-03 14:33 ` [dm-devel] " Mike Snitzer 2020-12-03 16:27 ` Keith Busch 2020-12-03 16:27 ` [dm-devel] " Keith Busch 2020-12-03 17:56 ` Mike Snitzer 2020-12-03 17:56 ` [dm-devel] " Mike Snitzer 2020-12-04 1:45 ` Ming Lei 2020-12-04 1:45 ` [dm-devel] " Ming Lei 2020-12-04 2:11 ` Mike Snitzer 2020-12-04 2:11 ` [dm-devel] " Mike Snitzer 2020-12-04 6:22 ` Damien Le Moal 2020-12-04 6:22 ` Damien Le Moal 2020-12-04 1:12 ` Ming Lei [this message] 2020-12-04 1:12 ` Ming Lei 2020-12-04 2:03 ` Mike Snitzer 2020-12-04 2:03 ` [dm-devel] " Mike Snitzer 2020-12-04 3:59 ` Ming Lei 2020-12-04 3:59 ` [dm-devel] " Ming Lei 2020-12-04 16:47 ` Mike Snitzer 2020-12-04 16:47 ` [dm-devel] " Mike Snitzer 2020-12-04 17:32 ` [RFC PATCH] dm: fix IO splitting [was: Re: [PATCH v2] block: use gcd() to fix chunk_sectors limit stacking] Mike Snitzer 2020-12-04 17:32 ` [dm-devel] " Mike Snitzer 2020-12-04 17:49 ` Mike Snitzer 2020-12-04 17:49 ` [dm-devel] " Mike Snitzer
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=20201204011243.GB661914@T590 \ --to=ming.lei@redhat.com \ --cc=axboe@kernel.dk \ --cc=bjohnsto@redhat.com \ --cc=dm-devel@redhat.com \ --cc=jdorminy@redhat.com \ --cc=linux-block@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=snitzer@redhat.com \ /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.