From: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To: "lsf-pc@lists.linux-foundation.org" <lsf-pc@lists.linux-foundation.org>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"linux-btrace@vger.kernel.org" <linux-btrace@vger.kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Bart Van Assche <bvanassche@acm.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Christoph Hellwig <hch@lst.de>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Hannes Reinecke <hare@suse.de>,
Johannes Thumshirn <jthumshirn@suse.de>,
Keith Busch <kbusch@kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Ming Lei <ming.lei@redhat.com>, Omar Sandoval <osandov@fb.com>,
Matias Bjorling <Matias.Bjorling@wdc.com>
Subject: Re: [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: add blktrace extension support
Date: Thu, 19 Dec 2019 05:50:16 +0000 [thread overview]
Message-ID: <BYAPR04MB5749EDD9E5928E769413B38086520@BYAPR04MB5749.namprd04.prod.outlook.com> (raw)
In-Reply-To: BYAPR04MB5749B4DC50C43EE845A04612865A0@BYAPR04MB5749.namprd04.prod.outlook.com
Adding Damien to this thread.
On 12/10/2019 10:17 PM, Chaitanya Kulkarni wrote:
> Hi,
>
> * Background:-
> -----------------------------------------------------------------------
>
> Linux Kernel Block layer now supports new Zone Management operations
> (REQ_OP_ZONE_[OPEN/CLOSE/FINISH] [1]).
>
> These operations are added mainly to support NVMe Zoned Namespces
> (ZNS) [2]. We are adding support for ZNS in Linux Kernel Block layer,
> user-space tools (sys-utils/nvme-cli), NVMe driver, File Systems,
> Device-mapper in order to support these devices in the field.
>
> Over the years Linux kernel block layer tracing infrastructure
> has proven to be not only extremely useful but essential for:-
>
> 1. Debugging the problems in the development of kernel block drivers.
> 2. Solving the issues at the customer sites.
> 3. Speeding up the development for the file system developers.
> 4. Finding the device-related issues on the fly without modifying
> the kernel.
> 5. Building white box test-cases around the complex areas in the
> linux-block layer.
>
> * Problem with block layer tracing infrastructure:-
> -----------------------------------------------------------------------
>
> If blktrace is such a great tool why we need this session for ?
>
> Existing blktrace infrastructure lacks the number of free bits that are
> available to track the new trace category. With the addition of new
> REQ_OP_ZONE_XXX we need more bits to expand the blktrace so that we can
> track more number of requests.
>
> * Current state of the work:-
> -----------------------------------------------------------------------
>
> RFC implementations [3] has been posted with the addition of new IOCTLs
> which is far from the production so that it can provide a basis to get
> the discussion started.
>
> This RFC implementation provides:-
> 1. Extended bits to track new trace categories.
> 2. Support for tracing per trace priorities.
> 3. Support for priority mask.
> 4. New IOCTLs so that user-space tools can setup the extensions.
> 5. Ability to track the integrity fields.
> 6. blktrace and blkparse implementation which supports the above
> mentioned features.
>
> Bart and Martin has suggested changes which I've incorporated in the RFC
> revisions.
>
> * What we will discuss in the proposed session ?
> -----------------------------------------------------------------------
>
> I'd like to propose a session for Storage track to go over the following
> discussion points:-
>
> 1. What is the right approach to move this work forward?
> 2. What are the other information bits we need to add which will help
> kernel community to speed up the development and improve tracing?
> 3. What are the other tracepoints we need to add in the block layer
> to improve the tracing?
> 4. What are device driver callbacks tracing we can add in the block
> layer?
> 5. Since polling is becoming popular what are the new tracepoints
> we need to improve debugging ?
>
>
> * Required Participants:-
> -----------------------------------------------------------------------
>
> I'd like to invite block layer, device drivers and file system
> developers to:-
>
> 1. Share their opinion on the topic.
> 2. Share their experience and any other issues with blktrace
> infrastructure.
> 3. Uncover additional details that are missing from this proposal.
>
> Regards,
> Chaitanya
>
> References :-
>
> [1] https://www.spinics.net/lists/linux-block/msg46043.html
> [2] https://nvmexpress.org/new-nvmetm-specification-defines-zoned-
> namespaces-zns-as-go-to-industry-technology/
> [3] https://www.spinics.net/lists/linux-btrace/msg01106.html
> https://www.spinics.net/lists/linux-btrace/msg01002.html
> https://www.spinics.net/lists/linux-btrace/msg01042.html
> https://www.spinics.net/lists/linux-btrace/msg00880.html
>
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-12-19 5:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 6:16 [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: add blktrace extension support Chaitanya Kulkarni
2019-12-12 22:19 ` Keith Busch
2019-12-19 5:50 ` Chaitanya Kulkarni [this message]
2020-01-09 10:19 ` Hans Holmberg
2020-01-09 12:59 ` Damien Le Moal
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=BYAPR04MB5749EDD9E5928E769413B38086520@BYAPR04MB5749.namprd04.prod.outlook.com \
--to=chaitanya.kulkarni@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=Matias.Bjorling@wdc.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jthumshirn@suse.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrace@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=osandov@fb.com \
--cc=tytso@mit.edu \
/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).