On 08/08/2015 11:02 AM, Kent Overstreet wrote:
> On Sat, Aug 08, 2015 at 10:52:24AM +0200, Hannes Reinecke wrote:
>> Wouldn't it be easier to move both max_write_same_sectors and
>> max_discard sectors to 64 bit (ie to type sector_t) and be done with the
>> overflow?
>> Seems to me this is far too
On 08/08/2015 11:02 AM, Kent Overstreet wrote:
On Sat, Aug 08, 2015 at 10:52:24AM +0200, Hannes Reinecke wrote:
Wouldn't it be easier to move both max_write_same_sectors and
max_discard sectors to 64 bit (ie to type sector_t) and be done with the
overflow?
Seems to me this is far too much
On Tue, 2015-08-11 at 20:24 -0400, Martin K. Petersen wrote:
> > "Ming" == Ming Lin writes:
>
> Ming> Do you still agree we cap discard to 2G as an interim solution?
>
> I can live with the 2G cap for 4.3 but would like to see it fixed
> properly in 4.4.
Sure. I'd like to work on the fix.
> "Ming" == Ming Lin writes:
Ming> Do you still agree we cap discard to 2G as an interim solution?
I can live with the 2G cap for 4.3 but would like to see it fixed
properly in 4.4.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line
On Tue, 2015-08-11 at 14:05 -0400, Martin K. Petersen wrote:
> > "Martin" == Martin K Petersen writes:
>
> Martin> I agree except I really don't want to lop off anything unless
> Martin> the device locks up if we send it partial blocks. There was an
> Martin> array that had problems a while
> "Martin" == Martin K Petersen writes:
Martin> I agree except I really don't want to lop off anything unless
Martin> the device locks up if we send it partial blocks. There was an
Martin> array that had problems a while back but I believe they have
Martin> been fixed.
Oh, and there are
> "Mike" == Mike Snitzer writes:
Mike> That is the benefit. And when coupled with the new default
Mike> max_discard of 64K (pending change from Jens for 4.3) this 2GB
Mike> upper limit really isn't such a big deal. Unless I'm missing
Mike> something...
2GB is fine for current SATA due to
> "Kent" == Kent Overstreet writes:
Kent> This kind of logic really doesn't belong in dm
Well it does in this case since the thinp personality actually
provisions and unprovisions space.
But there is a difference between what dm thinp acts on for its own
internal provisioning purposes and
On Tue, Aug 11 2015 at 1:36pm -0400,
Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike> DM-thinp processes discards internally before it passes them down
> Mike> (if configured to do so). If a discard is smaller than the
> Mike> granularity of a thinp block (whose
> "Mike" == Mike Snitzer writes:
Mike> DM-thinp processes discards internally before it passes them down
Mike> (if configured to do so). If a discard is smaller than the
Mike> granularity of a thinp block (whose size is configurable) or if
Mike> the start and end of the discard's extent is
On Mon, Aug 10 2015 at 11:38pm -0400,
Kent Overstreet wrote:
> On Mon, Aug 10, 2015 at 10:41:55PM -0400, Mike Snitzer wrote:
> > On Mon, Aug 10 2015 at 10:00pm -0400,
> > Martin K. Petersen wrote:
> >
> > > > "Ming" == Ming Lin writes:
> > >
> > > Ming> Did you mean still use (UINT_MAX
On Tue, 2015-08-11 at 14:05 -0400, Martin K. Petersen wrote:
Martin == Martin K Petersen martin.peter...@oracle.com writes:
Martin I agree except I really don't want to lop off anything unless
Martin the device locks up if we send it partial blocks. There was an
Martin array that had
On Mon, Aug 10 2015 at 11:38pm -0400,
Kent Overstreet kent.overstr...@gmail.com wrote:
On Mon, Aug 10, 2015 at 10:41:55PM -0400, Mike Snitzer wrote:
On Mon, Aug 10 2015 at 10:00pm -0400,
Martin K. Petersen martin.peter...@oracle.com wrote:
Ming == Ming Lin m...@kernel.org writes:
On Tue, Aug 11 2015 at 1:36pm -0400,
Martin K. Petersen martin.peter...@oracle.com wrote:
Mike == Mike Snitzer snit...@redhat.com writes:
Mike DM-thinp processes discards internally before it passes them down
Mike (if configured to do so). If a discard is smaller than the
Mike
Martin == Martin K Petersen martin.peter...@oracle.com writes:
Martin I agree except I really don't want to lop off anything unless
Martin the device locks up if we send it partial blocks. There was an
Martin array that had problems a while back but I believe they have
Martin been fixed.
Oh,
Mike == Mike Snitzer snit...@redhat.com writes:
Mike That is the benefit. And when coupled with the new default
Mike max_discard of 64K (pending change from Jens for 4.3) this 2GB
Mike upper limit really isn't such a big deal. Unless I'm missing
Mike something...
2GB is fine for current SATA
Mike == Mike Snitzer snit...@redhat.com writes:
Mike DM-thinp processes discards internally before it passes them down
Mike (if configured to do so). If a discard is smaller than the
Mike granularity of a thinp block (whose size is configurable) or if
Mike the start and end of the discard's
Kent == Kent Overstreet kent.overstr...@gmail.com writes:
Kent This kind of logic really doesn't belong in dm
Well it does in this case since the thinp personality actually
provisions and unprovisions space.
But there is a difference between what dm thinp acts on for its own
internal
Ming == Ming Lin m...@kernel.org writes:
Ming Do you still agree we cap discard to 2G as an interim solution?
I can live with the 2G cap for 4.3 but would like to see it fixed
properly in 4.4.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line
On Tue, 2015-08-11 at 20:24 -0400, Martin K. Petersen wrote:
Ming == Ming Lin m...@kernel.org writes:
Ming Do you still agree we cap discard to 2G as an interim solution?
I can live with the 2G cap for 4.3 but would like to see it fixed
properly in 4.4.
Sure. I'd like to work on the fix.
On Mon, Aug 10, 2015 at 10:41:55PM -0400, Mike Snitzer wrote:
> On Mon, Aug 10 2015 at 10:00pm -0400,
> Martin K. Petersen wrote:
>
> > > "Ming" == Ming Lin writes:
> >
> > Ming> Did you mean still use (UINT_MAX >> 9) in blkdev_issue_discard()?
> >
> > Ming> But that doesn't work for
On Mon, Aug 10 2015 at 10:00pm -0400,
Martin K. Petersen wrote:
> > "Ming" == Ming Lin writes:
>
> Ming> Did you mean still use (UINT_MAX >> 9) in blkdev_issue_discard()?
>
> Ming> But that doesn't work for dm-thinp. See Kent's suggestion to use
> Ming> 1<<31.
>
> I'm not sure why things
> "Ming" == Ming Lin writes:
Ming> Did you mean still use (UINT_MAX >> 9) in blkdev_issue_discard()?
Ming> But that doesn't work for dm-thinp. See Kent's suggestion to use
Ming> 1<<31.
I'm not sure why things are not working for dm-thinp. Presumably Kent's
code would split the discard at a
On Mon, Aug 10, 2015 at 11:13 AM, Mike Snitzer wrote:
> On Mon, Aug 10 2015 at 12:14pm -0400,
> Ming Lin wrote:
>
>> On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
>> >
>> > Aside from that, I'm in favor of seeing this late bio splitting patchset
>> > finally land upstream (hopefully in
On Mon, 2015-08-10 at 12:22 -0400, Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike> Shouldn't we also be using MAX_BIO_SECTORS in
> Mike> blkdev_issue_write_same (instead of UINT_MAX >> 9)?
>
> The granularity of WRITE SAME is always 1 logical block and there is no
>
On Mon, Aug 10 2015 at 12:14pm -0400,
Ming Lin wrote:
> On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
> >
> > Aside from that, I'm in favor of seeing this late bio splitting patchset
> > finally land upstream (hopefully in time for the 4.3 merge, Jens?):
> >
> > Acked-by: Mike Snitzer
> "Ming" == Ming Lin writes:
Ming,
Ming> I also prefer using MAX_BIO_SECTORS. Otherwise, we may have non
Ming> page size aligned splits.
This does not matter for write same and discard since there is only a
single logical block of payload. Also, given limitations in SATA we're
always
> "Mike" == Mike Snitzer writes:
Mike> Shouldn't we also be using MAX_BIO_SECTORS in
Mike> blkdev_issue_write_same (instead of UINT_MAX >> 9)?
The granularity of WRITE SAME is always 1 logical block and there is no
reason to round it down to the next power of two.
+/*
+ * Ensure that max
On Mon, 2015-08-10 at 09:14 -0700, Ming Lin wrote:
> On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
> > On Sun, Aug 09 2015 at 3:18am -0400,
> > Ming Lin wrote:
> >
> > > On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
> > > > On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
> On Sun, Aug 09 2015 at 3:18am -0400,
> Ming Lin wrote:
>
> > On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
> > > On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
> > > > Will change it to MAX_BIO_SECTORS.
> > > >
On Sun, Aug 09 2015 at 3:18am -0400,
Ming Lin wrote:
> On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
> > On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
> > > Will change it to MAX_BIO_SECTORS.
> > > May I add your ACK?
> >
> > Yes, please go ahead.
>
> Thanks. I'll
On Mon, 2015-08-10 at 09:14 -0700, Ming Lin wrote:
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
On Sun, Aug 09 2015 at 3:18am -0400,
Ming Lin m...@kernel.org wrote:
On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming
On Sun, Aug 09 2015 at 3:18am -0400,
Ming Lin m...@kernel.org wrote:
On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
Will change it to MAX_BIO_SECTORS.
May I add your ACK?
Yes, please go ahead.
Thanks. I'll
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
On Sun, Aug 09 2015 at 3:18am -0400,
Ming Lin m...@kernel.org wrote:
On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
Will change it to MAX_BIO_SECTORS.
May
Mike == Mike Snitzer snit...@redhat.com writes:
Mike Shouldn't we also be using MAX_BIO_SECTORS in
Mike blkdev_issue_write_same (instead of UINT_MAX 9)?
The granularity of WRITE SAME is always 1 logical block and there is no
reason to round it down to the next power of two.
+/*
+ * Ensure
On Mon, Aug 10 2015 at 12:14pm -0400,
Ming Lin m...@kernel.org wrote:
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
Aside from that, I'm in favor of seeing this late bio splitting patchset
finally land upstream (hopefully in time for the 4.3 merge, Jens?):
Acked-by: Mike
On Mon, 2015-08-10 at 12:22 -0400, Martin K. Petersen wrote:
Mike == Mike Snitzer snit...@redhat.com writes:
Mike Shouldn't we also be using MAX_BIO_SECTORS in
Mike blkdev_issue_write_same (instead of UINT_MAX 9)?
The granularity of WRITE SAME is always 1 logical block and there is no
Ming == Ming Lin m...@kernel.org writes:
Ming,
Ming I also prefer using MAX_BIO_SECTORS. Otherwise, we may have non
Ming page size aligned splits.
This does not matter for write same and discard since there is only a
single logical block of payload. Also, given limitations in SATA we're
On Mon, Aug 10, 2015 at 11:13 AM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Aug 10 2015 at 12:14pm -0400,
Ming Lin m...@kernel.org wrote:
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote:
Aside from that, I'm in favor of seeing this late bio splitting patchset
finally land
On Mon, Aug 10, 2015 at 10:41:55PM -0400, Mike Snitzer wrote:
On Mon, Aug 10 2015 at 10:00pm -0400,
Martin K. Petersen martin.peter...@oracle.com wrote:
Ming == Ming Lin m...@kernel.org writes:
Ming Did you mean still use (UINT_MAX 9) in blkdev_issue_discard()?
Ming But that
Ming == Ming Lin m...@kernel.org writes:
Ming Did you mean still use (UINT_MAX 9) in blkdev_issue_discard()?
Ming But that doesn't work for dm-thinp. See Kent's suggestion to use
Ming 131.
I'm not sure why things are not working for dm-thinp. Presumably Kent's
code would split the discard at
On Mon, Aug 10 2015 at 10:00pm -0400,
Martin K. Petersen martin.peter...@oracle.com wrote:
Ming == Ming Lin m...@kernel.org writes:
Ming Did you mean still use (UINT_MAX 9) in blkdev_issue_discard()?
Ming But that doesn't work for dm-thinp. See Kent's suggestion to use
Ming 131.
I'm
On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
> On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
> > Will change it to MAX_BIO_SECTORS.
> > May I add your ACK?
>
> Yes, please go ahead.
Thanks. I'll send a new version of the series once device-mapper guy
acks.
Hi Mike,
I
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
> Will change it to MAX_BIO_SECTORS.
> May I add your ACK?
Yes, please go ahead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Sat, 2015-08-08 at 23:41 -0700, Christoph Hellwig wrote:
> On Sat, Aug 08, 2015 at 10:59:50PM -0700, Ming Lin wrote:
> > +/*
> > + * Ensure that max discard sectors doesn't overflow bi_size and hopefully
> > + * it is of the proper granularity as long as the granularity is a power
> > + * of
On Sat, Aug 08, 2015 at 10:59:50PM -0700, Ming Lin wrote:
> +/*
> + * Ensure that max discard sectors doesn't overflow bi_size and hopefully
> + * it is of the proper granularity as long as the granularity is a power
> + * of two.
> + */
> +#define MAX_DISCARD_SECTORS ((1U << 31) >> 9)
Thisn't
On Sat, 2015-08-08 at 12:19 -0400, Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike> This will translate to all intermediate layers that might split
> Mike> discards needing to worry about granularity/alignment too
> Mike> (e.g. how dm-thinp will have to care because it
On Sat, 2015-08-08 at 12:19 -0400, Martin K. Petersen wrote:
Mike == Mike Snitzer snit...@redhat.com writes:
Mike This will translate to all intermediate layers that might split
Mike discards needing to worry about granularity/alignment too
Mike (e.g. how dm-thinp will have to care because
On Sat, Aug 08, 2015 at 10:59:50PM -0700, Ming Lin wrote:
+/*
+ * Ensure that max discard sectors doesn't overflow bi_size and hopefully
+ * it is of the proper granularity as long as the granularity is a power
+ * of two.
+ */
+#define MAX_DISCARD_SECTORS ((1U 31) 9)
Thisn't isn't
On Sat, 2015-08-08 at 23:41 -0700, Christoph Hellwig wrote:
On Sat, Aug 08, 2015 at 10:59:50PM -0700, Ming Lin wrote:
+/*
+ * Ensure that max discard sectors doesn't overflow bi_size and hopefully
+ * it is of the proper granularity as long as the granularity is a power
+ * of two.
+ */
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
Will change it to MAX_BIO_SECTORS.
May I add your ACK?
Yes, please go ahead.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote:
On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote:
Will change it to MAX_BIO_SECTORS.
May I add your ACK?
Yes, please go ahead.
Thanks. I'll send a new version of the series once device-mapper guy
acks.
Hi Mike,
I have
> "Mike" == Mike Snitzer writes:
Mike> This will translate to all intermediate layers that might split
Mike> discards needing to worry about granularity/alignment too
Mike> (e.g. how dm-thinp will have to care because it must generate
Mike> discard mappings with associated bios based on how
On Fri, Aug 07, 2015 at 09:22:26PM -0800, Kent Overstreet wrote:
> Is granularity required to be a power of two? One would hope, but looking at
> the
> code that doesn't appear to be a requirement... ugh, that's terrible...
If devices have an odd granularity we'll just have to split more than
On Sat, Aug 08, 2015 at 10:52:24AM +0200, Hannes Reinecke wrote:
> Wouldn't it be easier to move both max_write_same_sectors and
> max_discard sectors to 64 bit (ie to type sector_t) and be done with the
> overflow?
> Seems to me this is far too much coding around self-imposed restrictions...
On 08/08/2015 01:40 AM, Ming Lin wrote:
>
> On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
>> I'm for solution 3:
>>
>> - keep blk_bio_{discard,write_same}_split, but ensure we never built
>>a > 4GB bio in blkdev_issue_{discard,write_same}.
>
> This has problem as I mentioned
On 08/08/2015 01:40 AM, Ming Lin wrote:
On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
a 4GB bio in blkdev_issue_{discard,write_same}.
This has problem as I mentioned in solution 1.
On Sat, Aug 08, 2015 at 10:52:24AM +0200, Hannes Reinecke wrote:
Wouldn't it be easier to move both max_write_same_sectors and
max_discard sectors to 64 bit (ie to type sector_t) and be done with the
overflow?
Seems to me this is far too much coding around self-imposed restrictions...
It's
On Fri, Aug 07, 2015 at 09:22:26PM -0800, Kent Overstreet wrote:
Is granularity required to be a power of two? One would hope, but looking at
the
code that doesn't appear to be a requirement... ugh, that's terrible...
If devices have an odd granularity we'll just have to split more than
Mike == Mike Snitzer snit...@redhat.com writes:
Mike This will translate to all intermediate layers that might split
Mike discards needing to worry about granularity/alignment too
Mike (e.g. how dm-thinp will have to care because it must generate
Mike discard mappings with associated bios based
On Fri, Aug 07, 2015 at 10:17:43PM -0700, Ming Lin wrote:
> On Fri, Aug 7, 2015 at 5:30 PM, Kent Overstreet
> > Ideally we'd get upper layers out of the business of knowing about the queue
> > limits at all - that was the point of the patch series, after all.
> >
> > Instead of using UINT_MAX,
On Fri, Aug 7, 2015 at 5:30 PM, Kent Overstreet
wrote:
> On Fri, Aug 07, 2015 at 04:40:06PM -0700, Ming Lin wrote:
>>
>> On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
>> > I'm for solution 3:
>> >
>> > - keep blk_bio_{discard,write_same}_split, but ensure we never built
>> >a >
On Fri, Aug 07, 2015 at 04:40:06PM -0700, Ming Lin wrote:
>
> On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
> > I'm for solution 3:
> >
> > - keep blk_bio_{discard,write_same}_split, but ensure we never built
> >a > 4GB bio in blkdev_issue_{discard,write_same}.
>
> This has
On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
> I'm for solution 3:
>
> - keep blk_bio_{discard,write_same}_split, but ensure we never built
>a > 4GB bio in blkdev_issue_{discard,write_same}.
This has problem as I mentioned in solution 1.
We need to also make sure max discard
On Thu, Aug 06, 2015 at 05:00:04PM -0700, Kent Overstreet wrote:
> Why is it that we don't want to send giant discards? Is it a latency issue?
Yes. Take a look at the "Configurable max discard size" thread(s).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
a > 4GB bio in blkdev_issue_{discard,write_same}.
Note that this isn't special casing, we can't build > 4GB bios for
data either, it's just implemented as a side effect right now instead
of checked
On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
a 4GB bio in blkdev_issue_{discard,write_same}.
This has problem as I mentioned in solution 1.
We need to also make sure max discard size
On Fri, Aug 07, 2015 at 04:40:06PM -0700, Ming Lin wrote:
On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
a 4GB bio in blkdev_issue_{discard,write_same}.
This has problem as I
On Fri, Aug 7, 2015 at 5:30 PM, Kent Overstreet
kent.overstr...@gmail.com wrote:
On Fri, Aug 07, 2015 at 04:40:06PM -0700, Ming Lin wrote:
On Fri, 2015-08-07 at 09:30 +0200, Christoph Hellwig wrote:
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
On Fri, Aug 07, 2015 at 10:17:43PM -0700, Ming Lin wrote:
On Fri, Aug 7, 2015 at 5:30 PM, Kent Overstreet
Ideally we'd get upper layers out of the business of knowing about the queue
limits at all - that was the point of the patch series, after all.
Instead of using UINT_MAX, would it
On Thu, Aug 06, 2015 at 05:00:04PM -0700, Kent Overstreet wrote:
Why is it that we don't want to send giant discards? Is it a latency issue?
Yes. Take a look at the Configurable max discard size thread(s).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
I'm for solution 3:
- keep blk_bio_{discard,write_same}_split, but ensure we never built
a 4GB bio in blkdev_issue_{discard,write_same}.
Note that this isn't special casing, we can't build 4GB bios for
data either, it's just implemented as a side effect right now instead
of checked
On Tue, Aug 04, 2015 at 01:36:26PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
> > I think the important thing is the late splitting for regular bio.
> > For discard/write_same bio, how about just don't do late splitting?
>
> I'd hate having to
On Tue, Aug 04, 2015 at 01:36:26PM +0200, Christoph Hellwig wrote:
On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
I think the important thing is the late splitting for regular bio.
For discard/write_same bio, how about just don't do late splitting?
I'd hate having to special
On Tue, 2015-08-04 at 13:36 +0200, Christoph Hellwig wrote:
> On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
> > I think the important thing is the late splitting for regular bio.
> > For discard/write_same bio, how about just don't do late splitting?
>
> I'd hate having to special
On Tue, 2015-08-04 at 13:36 +0200, Christoph Hellwig wrote:
On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
I think the important thing is the late splitting for regular bio.
For discard/write_same bio, how about just don't do late splitting?
I'd hate having to special case them
On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
> I think the important thing is the late splitting for regular bio.
> For discard/write_same bio, how about just don't do late splitting?
I'd hate having to special case them even more. Especially as the
discard splitting is nasty and we
On Sun, Aug 02, 2015 at 10:58:22PM -0700, Ming Lin wrote:
I think the important thing is the late splitting for regular bio.
For discard/write_same bio, how about just don't do late splitting?
I'd hate having to special case them even more. Especially as the
discard splitting is nasty and we
On Sat, 2015-08-01 at 12:33 -0400, Mike Snitzer wrote:
> On Sat, Aug 01 2015 at 2:58am -0400,
> Ming Lin wrote:
>
> > On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> > >
> > > OK, once setup, to run the 2 tests in question directly you'd do
> > > something like:
> > >
> > > dmtest
On Sat, 2015-08-01 at 12:33 -0400, Mike Snitzer wrote:
On Sat, Aug 01 2015 at 2:58am -0400,
Ming Lin m...@kernel.org wrote:
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
OK, once setup, to run the 2 tests in question directly you'd do
something like:
dmtest run
On Sat, Aug 01 2015 at 2:58am -0400,
Ming Lin wrote:
> On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> >
> > OK, once setup, to run the 2 tests in question directly you'd do
> > something like:
> >
> > dmtest run --suite thin-provisioning -n discard_a_fragmented_device
> >
> >
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> On Fri, Jul 31 2015 at 5:19pm -0400,
> Ming Lin wrote:
>
> > On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer wrote:
> > > On Mon, Jul 06 2015 at 3:44P -0400,
> > > Ming Lin wrote:
> > >
> > >> From: Kent Overstreet
> > >>
> > >> The
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
On Fri, Jul 31 2015 at 5:19pm -0400,
Ming Lin m...@kernel.org wrote:
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin m...@kernel.org wrote:
From: Kent
On Sat, Aug 01 2015 at 2:58am -0400,
Ming Lin m...@kernel.org wrote:
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
OK, once setup, to run the 2 tests in question directly you'd do
something like:
dmtest run --suite thin-provisioning -n discard_a_fragmented_device
On Fri, Jul 31, 2015 at 3:02 PM, Ming Lin wrote:
> On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
>> On Fri, Jul 31 2015 at 5:19pm -0400,
>> Ming Lin wrote:
>>
>> > On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer wrote:
>> > > On Mon, Jul 06 2015 at 3:44P -0400,
>> > > Ming Lin wrote:
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> On Fri, Jul 31 2015 at 5:19pm -0400,
> Ming Lin wrote:
>
> > On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer wrote:
> > > On Mon, Jul 06 2015 at 3:44P -0400,
> > > Ming Lin wrote:
> > >
> > >> From: Kent Overstreet
> > >>
> > >> The
On Fri, Jul 31 2015 at 5:19pm -0400,
Ming Lin wrote:
> On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer wrote:
> > On Mon, Jul 06 2015 at 3:44P -0400,
> > Ming Lin wrote:
> >
> >> From: Kent Overstreet
> >>
> >> The way the block layer is currently written, it goes to great lengths
> >> to
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer wrote:
> On Mon, Jul 06 2015 at 3:44P -0400,
> Ming Lin wrote:
>
>> From: Kent Overstreet
>>
>> The way the block layer is currently written, it goes to great lengths
>> to avoid having to split bios; upper layer code (such as bio_add_page())
>>
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin wrote:
> From: Kent Overstreet
>
> The way the block layer is currently written, it goes to great lengths
> to avoid having to split bios; upper layer code (such as bio_add_page())
> checks what the underlying device can handle and tries to always
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin m...@kernel.org wrote:
From: Kent Overstreet kent.overstr...@gmail.com
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying
On Fri, Jul 31 2015 at 5:19pm -0400,
Ming Lin m...@kernel.org wrote:
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin m...@kernel.org wrote:
From: Kent Overstreet kent.overstr...@gmail.com
The way the block layer
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin m...@kernel.org wrote:
From: Kent Overstreet kent.overstr...@gmail.com
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios;
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
On Fri, Jul 31 2015 at 5:19pm -0400,
Ming Lin m...@kernel.org wrote:
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Jul 06 2015 at 3:44P -0400,
Ming Lin m...@kernel.org wrote:
From: Kent
On Fri, Jul 31, 2015 at 3:02 PM, Ming Lin m...@kernel.org wrote:
On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
On Fri, Jul 31 2015 at 5:19pm -0400,
Ming Lin m...@kernel.org wrote:
On Fri, Jul 31, 2015 at 12:23 PM, Mike Snitzer snit...@redhat.com wrote:
On Mon, Jul 06 2015 at
From: Kent Overstreet
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.
But this approach
From: Kent Overstreet
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.
But this approach
From: Kent Overstreet kent.overstr...@gmail.com
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.
From: Kent Overstreet kent.overstr...@gmail.com
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.
98 matches
Mail list logo
