From: Boaz Harrosh <boaz@plexistor.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>,
Andreas Dilger <adilger@dilger.ca>
Cc: Jens Axboe <axboe@fb.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
calvinowens@fb.com, hch@lst.de
Subject: Re: [PATCH 0/11] Update version of write stream ID patchset
Date: Sun, 06 Mar 2016 18:08:04 +0200 [thread overview]
Message-ID: <56DC55E4.8070205@plexistor.com> (raw)
In-Reply-To: <yq1fuw33gix.fsf@sermon.lab.mkp.net>
On 03/06/2016 03:03 PM, Martin K. Petersen wrote:
>>>>>> "Andreas" == Andreas Dilger <adilger@dilger.ca> writes:
>
> Andreas,
>
> Andreas> What are your thoughts on reserving a small number of the
> Andreas> stream ID values for filesystem metadata (e.g. the first 31
> Andreas> since 0 == unused)?
>
> The stream ID address space might be 16-bit but the devices currently
> being discussed can only handle a few concurrently open streams (4, 8,
> 16).
>
So I can't for the life of me understand what is the use of all this.
If what Jens said at beginning for data grouping than what is it at all
got to do with open and close of anything? Really?
Does it make any sense to you? I mean with multy-queue with HW channels
for every CPU, parallel IO, and poling because even interrupts are too
slow, you want me to cram everything and serialize it on 4 open/close
streams?
Either I'm completely missing something. Or please please explain
what is going on. How does 4 stream make any sense in today's NvME
HW? How does open/close anything make any sense?
On the surface it looks like someone is smoking something really
bad.
> Discussions are ongoing about whether the devices should be able to
> implicitly close a stream based on LRU or something similar when the hw
> max is reached. But as it stands you have to explicitly close an
> existing stream with a separate command when the max is reached.
> Otherwise a write with a previously unused stream ID will fail.
>
?? (see smoking above ;-) )
> I.e. there is a significant cost to switching between stream IDs and
> thus I am afraid the current stuff isn't well suited to having a fine
> grained tagging approach like the one you are proposing.
>
So again who cares for anything that hurts performance? Why would
I want to use anything that has "significant cost" at all?
Thanks
Boaz
next prev parent reply other threads:[~2016-03-06 16:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 16:10 [PATCH 0/11] Update version of write stream ID patchset Jens Axboe
2016-03-04 16:10 ` [PATCH 01/11] idr: make ida_simple_remove() return an error Jens Axboe
2016-03-04 16:10 ` [PATCH 02/11] block: add support for carrying a stream ID in a bio Jens Axboe
2016-03-04 16:10 ` [PATCH 03/11] Add support for per-file/inode stream ID Jens Axboe
[not found] ` <CAJVOszBXU-qQENcOGG8pWeARwoWL2G3gNJ0H2uNPjXkiVa8S+Q@mail.gmail.com>
2016-03-04 20:35 ` Jens Axboe
2016-03-04 16:10 ` [PATCH 04/11] Add system call for setting inode/file write " Jens Axboe
2016-03-04 16:10 ` [PATCH 05/11] wire up system call for x86/x86-64 Jens Axboe
2016-03-04 16:10 ` [PATCH 06/11] Add support for bdi tracking of stream ID Jens Axboe
2016-03-04 16:10 ` [PATCH 07/11] direct-io: add support for write stream IDs Jens Axboe
2016-03-04 16:10 ` [PATCH 08/11] Add stream ID support for buffered mpage/__block_write_full_page() Jens Axboe
2016-03-04 16:10 ` [PATCH 09/11] btrfs: add support for write stream IDs Jens Axboe
2016-03-04 20:44 ` Chris Mason
2016-03-04 20:45 ` Jens Axboe
2016-03-04 16:10 ` [PATCH 10/11] xfs: add support for buffered writeback stream ID Jens Axboe
2016-03-04 16:10 ` [PATCH 11/11] ext4: add support for write stream IDs Jens Axboe
2016-03-04 19:42 ` [PATCH 0/11] Update version of write stream ID patchset Jeff Moyer
2016-03-04 20:34 ` Jens Axboe
2016-03-04 21:01 ` Jeff Moyer
2016-03-04 21:06 ` Jens Axboe
2016-03-04 22:03 ` Jeff Moyer
2016-03-04 22:13 ` Jens Axboe
2016-03-05 20:48 ` Martin K. Petersen
2016-03-08 21:56 ` Jens Axboe
2016-03-17 23:43 ` Dan Williams
2016-03-18 0:18 ` Jens Axboe
2016-03-18 2:39 ` Martin K. Petersen
2016-03-18 17:37 ` Jens Axboe
2016-03-18 17:56 ` Dan Williams
2016-03-06 6:13 ` Andreas Dilger
2016-03-06 13:03 ` Martin K. Petersen
2016-03-06 16:08 ` Boaz Harrosh [this message]
2016-03-06 20:51 ` Shaun Tancheff
2016-03-07 15:41 ` Martin K. Petersen
2016-03-07 15:34 ` Martin K. Petersen
2016-03-06 22:42 ` Andreas Dilger
2016-03-07 15:52 ` Martin K. Petersen
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=56DC55E4.8070205@plexistor.com \
--to=boaz@plexistor.com \
--cc=adilger@dilger.ca \
--cc=axboe@fb.com \
--cc=calvinowens@fb.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=martin.petersen@oracle.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.