All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Matias Bjørling" <m@bjorling.me>, "Jens Axboe" <axboe@fb.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: ming.l@ssi.samsung.com
Subject: Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio
Date: Tue, 24 Mar 2015 11:26:54 -0600	[thread overview]
Message-ID: <55119E5E.6020405@kernel.dk> (raw)
In-Reply-To: <55119AAE.9030202@bjorling.me>

On 03/24/2015 11:11 AM, Matias Bjørling wrote:
> On 03/24/2015 04:26 PM, Jens Axboe wrote:
>> The top bits of bio->bi_flags are reserved for keeping the
>> allocation pool, set aside the next four bits for carrying
>> a stream ID. That leaves us with support for 15 streams,
>> 0 is reserved as a "stream not set" value.
>
> 15 streams seem very limited. Can this be extended? e.g. 16 bits.
>
> 15 streams is enough for 1-4 applications. More, and applications starts
> to fight over the same stream id's, leading them to place different age
> data in same flash blocks and push us back to square one.
>
> I understand that Samsung multi-stream SSD supports a limited amount of
> streams, more advance implementations should provide higher limits.

Pushing it higher is not a big deal as far as the implementation goes, 
though 16 bits might be stealing a bit too much space for this. On 
32-bit archs, we have 18 bits currently free that we can abuse. The 
Samsung device supports 16 streams. That's honestly a lot more than I 
would expect most devices to support in hardware, 16 is a lot of open 
erase blocks and write append points. Obviously the open channel effort 
would make that more feasible, though.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: "Matias Bjørling" <m@bjorling.me>, "Jens Axboe" <axboe@fb.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: ming.l@ssi.samsung.com
Subject: Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio
Date: Tue, 24 Mar 2015 11:26:54 -0600	[thread overview]
Message-ID: <55119E5E.6020405@kernel.dk> (raw)
In-Reply-To: <55119AAE.9030202@bjorling.me>

On 03/24/2015 11:11 AM, Matias Bjørling wrote:
> On 03/24/2015 04:26 PM, Jens Axboe wrote:
>> The top bits of bio->bi_flags are reserved for keeping the
>> allocation pool, set aside the next four bits for carrying
>> a stream ID. That leaves us with support for 15 streams,
>> 0 is reserved as a "stream not set" value.
>
> 15 streams seem very limited. Can this be extended? e.g. 16 bits.
>
> 15 streams is enough for 1-4 applications. More, and applications starts
> to fight over the same stream id's, leading them to place different age
> data in same flash blocks and push us back to square one.
>
> I understand that Samsung multi-stream SSD supports a limited amount of
> streams, more advance implementations should provide higher limits.

Pushing it higher is not a big deal as far as the implementation goes, 
though 16 bits might be stealing a bit too much space for this. On 
32-bit archs, we have 18 bits currently free that we can abuse. The 
Samsung device supports 16 streams. That's honestly a lot more than I 
would expect most devices to support in hardware, 16 is a lot of open 
erase blocks and write append points. Obviously the open channel effort 
would make that more feasible, though.

-- 
Jens Axboe


  reply	other threads:[~2015-03-24 17:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24 15:26 [PATCH RFC] Support for write stream IDs Jens Axboe
2015-03-24 15:26 ` [PATCH 1/6] block: add support for carrying a stream ID in a bio Jens Axboe
2015-03-24 17:11   ` Matias Bjørling
2015-03-24 17:26     ` Jens Axboe [this message]
2015-03-24 17:26       ` Jens Axboe
2015-03-24 22:07       ` Ming Lin-SSI
2015-03-25  1:42         ` Jens Axboe
2015-03-25  1:42           ` Jens Axboe
2015-03-25  8:11         ` Matias Bjørling
2015-03-25 18:36           ` Ming Lin-SSI
2015-03-25  2:30   ` Dave Chinner
2015-04-12 10:42     ` Dmitry Monakhov
2015-03-24 15:26 ` [PATCH 2/6] Add support for per-file stream ID Jens Axboe
2015-03-24 15:27 ` [PATCH 3/6] direct-io: add support for write stream IDs Jens Axboe
2015-03-25  2:43   ` Dave Chinner
2015-03-25 14:26     ` Jens Axboe
2015-04-10 23:50       ` Ming Lin
2015-04-11  0:06         ` Ming Lin
2015-04-11 11:59         ` Dave Chinner
2015-04-17  6:20           ` Ming Lin
2015-04-17 23:06             ` Dave Chinner
2015-04-17 23:11               ` Jens Axboe
2015-04-17 23:51                 ` Dave Chinner
2015-04-18  2:00                   ` Jens Axboe
2015-04-17 15:17         ` Jens Axboe
2015-03-24 15:27 ` [PATCH 4/6] Add stream ID support for buffered writeback Jens Axboe
2015-03-25  2:40   ` Dave Chinner
2015-03-25 14:17     ` Jens Axboe
2015-03-24 15:27 ` [PATCH 5/6] btrfs: add support for buffered writeback stream ID Jens Axboe
2015-03-24 15:27 ` [PATCH 6/6] xfs: " Jens Axboe
2015-03-25  2:41   ` Dave Chinner
2015-03-24 17:03 ` [PATCH RFC] Support for write stream IDs Jeff Moyer
2015-03-24 17:08   ` Jens Axboe
2015-03-24 21:46     ` Ming Lin-SSI
2015-03-24 21:48       ` Jens Axboe

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=55119E5E.6020405@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=axboe@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m@bjorling.me \
    --cc=ming.l@ssi.samsung.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: link
Be 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.