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 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 "unsubsc
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 b
> "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 seve
> "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 t
> "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 w
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 size
> "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 m
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 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 dm-th
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 t
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
> re
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 issui
> "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 di
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 Li
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.
> > > > May
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 sen
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 http:/
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 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
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 m
> "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 b
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
nes
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 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
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, woul
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 pr
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 explic
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 speci
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
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 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
> >
> > dmtest
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 way
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 way
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 avo
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())
>> ch
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 c
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 become
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 become
49 matches
Mail list logo
