linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: 'Christoph Hellwig' <hch@infradead.org>
Cc: kanchan <joshi.k@samsung.com>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org, prakash.v@samsung.com,
	anshul@samsung.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal
Date: Tue, 21 May 2019 10:25:28 +0200	[thread overview]
Message-ID: <20190521082528.GA17709@quack2.suse.cz> (raw)
In-Reply-To: <20190520142719.GA15705@infradead.org>

On Mon 20-05-19 07:27:19, 'Christoph Hellwig' wrote:
> On Fri, May 17, 2019 at 11:01:55AM +0530, kanchan wrote:
> > Sorry but can you please elaborate the issue? I do not get what is being
> > statically allocated which was globally available earlier.
> > If you are referring to nvme driver,  available streams at subsystem level
> > are being reflected for all namespaces. This is same as earlier. 
> > There is no attempt to explicitly allocate (using dir-receive) or reserve
> > streams for any namespace.  
> > Streams will continue to get allocated/released implicitly as and when
> > writes (with stream id) arrive.
> 
> We have made a concious decision that we do not want to expose streams
> as an awkward not fish not flesh interface, but instead life time hints.
> 
> I see no reason to change from and burden the whole streams complexity
> on other in-kernel callers.

I'm not following the "streams complexity" you talk about. At least the
usecase Kanchan speaks about here is pretty simple for the filesystem -
tagging journal writes with special stream id. I agree that something like
dynamically allocating available stream ids to different purposes is
complex and has uncertain value but this "static stream id for particular
purpose" looks simple and sensible to me and Kanchan has shown significant
performance benefits for some drives. After all you can just think about it
like RWH_WRITE_LIFE_JOURNAL type of hint available for the kernel...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2019-05-21  8:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190425112347epcas2p1f7be48b8f0d2203252b8c9dd510c1b61@epcas2p1.samsung.com>
2019-04-25 11:19 ` [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal Kanchan Joshi
     [not found]   ` <CGME20190425112351epcas2p209fdb12872bdcdcb11afd7b6e196b85e@epcas2p2.samsung.com>
2019-04-25 11:19     ` [PATCH v5 1/7] fs: introduce write-hint start point for in-kernel hints Kanchan Joshi
     [not found]   ` <CGME20190425112355epcas2p11e197c8fc33698feb7150d1f4148407e@epcas2p1.samsung.com>
2019-04-25 11:19     ` [PATCH v5 2/7] block: increase stream count for in-kernel use Kanchan Joshi
     [not found]   ` <CGME20190425112358epcas1p13da4f182241366c309cb2c76df3fb048@epcas1p1.samsung.com>
2019-04-25 11:19     ` [PATCH v5 3/7] block: introduce API to register stream information with block-layer Kanchan Joshi
     [not found]   ` <CGME20190425112400epcas1p26e7634f95a185a83c31470006d291161@epcas1p2.samsung.com>
2019-04-25 11:19     ` [PATCH v5 4/7] block: introduce write-hint to stream-id conversion Kanchan Joshi
     [not found]   ` <CGME20190425112403epcas1p13006198cda351a08c8403c2b85c9f102@epcas1p1.samsung.com>
2019-04-25 11:20     ` [PATCH v5 5/7] nvme: register stream info with block layer Kanchan Joshi
     [not found]   ` <CGME20190425112406epcas1p4a54b2c5d15ae42a53ff3c206cf7a7892@epcas1p4.samsung.com>
2019-04-25 11:20     ` [PATCH v5 6/7] fs: introduce APIs to enable passing write-hint with buffer-head Kanchan Joshi
     [not found]   ` <CGME20190425112408epcas2p2ddba9fdf175645dd2647da191eac5e1c@epcas2p2.samsung.com>
2019-04-25 11:20     ` [PATCH v5 7/7] fs/ext4,jbd2: add support for sending write-hint with journal Kanchan Joshi
2019-05-10  5:31   ` [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal kanchan
2019-05-10 17:02   ` Christoph Hellwig
2019-05-17  5:31     ` kanchan
2019-05-20 14:27       ` 'Christoph Hellwig'
2019-05-21  8:25         ` Jan Kara [this message]
2019-05-21  8:28           ` 'Christoph Hellwig'
2019-05-22 10:25             ` Jan Kara
2019-06-26 12:47               ` kanchan
2019-06-28  7:25                 ` 'Christoph Hellwig'

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=20190521082528.GA17709@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=anshul@samsung.com \
    --cc=hch@infradead.org \
    --cc=joshi.k@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    --cc=prakash.v@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).