linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>
Cc: Ajay Joshi <Ajay.Joshi@wdc.com>,
	Matias Bjorling <Matias.Bjorling@wdc.com>,
	Hans Holmberg <Hans.Holmberg@wdc.com>,
	Dmitry Fomichev <Dmitry.Fomichev@wdc.com>,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 2/8] block: Simplify REQ_OP_ZONE_RESET_ALL handling
Date: Mon, 28 Oct 2019 08:37:17 +0000	[thread overview]
Message-ID: <BYAPR04MB57490F22E67DC5B172A3A9FE86660@BYAPR04MB5749.namprd04.prod.outlook.com> (raw)
In-Reply-To: BYAPR04MB58160668CEB54919B22AC2FBE7660@BYAPR04MB5816.namprd04.prod.outlook.com

On 10/28/19 12:54 AM, Damien Le Moal wrote:
> Isn't the trace point under submit_bio() in
> generic_make_request_checks() ? So removing the function is not a
> problem for tracing as far as I can tell. Am I missing something ?

Yes you are right, I completely missed that.

Sorry I've created confusion with block_dump and tracepoint.

Block trace code is fine.

The block_dump code under the submit_bio() is only dumps the bios with
the data:-


1171                 if (unlikely(block_dump)) {
1172                         char b[BDEVNAME_SIZE];
1173                         printk(KERN_DEBUG "%s(%d): %s block %Lu on 
%s (%u sectors)\n",
1174                         current->comm, task_pid_nr(current),
1175                                 op_is_write(bio_op(bio)) ? "WRITE" 
: "READ",
1176                                 (unsigned long 
long)bio->bi_iter.bi_sector,
1177                                 bio_devname(bio, b), count);
1178                 }


I've posted patch-series [1] in the past to move that code out but it 
didn't go anywhere in anticipation of more data less requests.

Since it is taking longer to have blktrace extensions RFC to move 
forward and [1] didn't go anywhere I wanted to use block_dump
parameter in the blk-zoned.c (not an ideal situation) so that we can 
have atleast minimal debug support for the new REQ_OP_ZONE_XXX 
operations until we get block trace extensions in the kernel.

Nonetheless, I'll just a send a patch on the top of this which will
make discussion much easier.


[1] :- 
https://lore.kernel.org/linux-block/DM6PR04MB57546ECC4CFDDB5535E3382586FB0@DM6PR04MB5754.namprd04.prod.outlook.com/T/

  reply	other threads:[~2019-10-28  8:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-27 14:05 [PATCH 0/8] Zone management commands support Damien Le Moal
2019-10-27 14:05 ` [PATCH 1/8] block: Remove REQ_OP_ZONE_RESET plugging Damien Le Moal
2019-10-28  7:50   ` Chaitanya Kulkarni
2019-10-29 12:13   ` Javier González
2019-11-07  9:50   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 2/8] block: Simplify REQ_OP_ZONE_RESET_ALL handling Damien Le Moal
2019-10-28  7:49   ` Chaitanya Kulkarni
2019-10-28  7:54     ` Damien Le Moal
2019-10-28  8:37       ` Chaitanya Kulkarni [this message]
2019-11-07  9:51   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 3/8] scsi: sd_zbc: Fix sd_zbc_complete() Damien Le Moal
2019-11-02  0:42   ` Martin K. Petersen
2019-10-27 14:05 ` [PATCH 4/8] block: add zone open, close and finish operations Damien Le Moal
2019-10-29 12:23   ` Javier González
2019-11-07  9:52   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 5/8] block: add zone open, close and finish ioctl support Damien Le Moal
2019-10-29 12:23   ` Javier González
2019-11-07  9:52   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 6/8] scsi: sd_zbc: add zone open, close, and finish support Damien Le Moal
2019-11-02  0:43   ` Martin K. Petersen
2019-11-07  9:53   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 7/8] dm: add zone open, close " Damien Le Moal
2019-11-05 16:34   ` Mike Snitzer
2019-11-07  9:53   ` Christoph Hellwig
2019-10-27 14:05 ` [PATCH 8/8] null_blk: add zone open, close, " Damien Le Moal
2019-11-07  9:54   ` Christoph Hellwig
2019-11-02  3:01 ` [PATCH 0/8] Zone management commands support Jens Axboe
2019-11-03 23:41   ` Damien Le Moal
2019-11-05  4:51     ` Martin K. Petersen
2019-11-05  5:08       ` Damien Le Moal
2019-11-07 13:40 ` 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=BYAPR04MB57490F22E67DC5B172A3A9FE86660@BYAPR04MB5749.namprd04.prod.outlook.com \
    --to=chaitanya.kulkarni@wdc.com \
    --cc=Ajay.Joshi@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=Dmitry.Fomichev@wdc.com \
    --cc=Hans.Holmberg@wdc.com \
    --cc=Matias.Bjorling@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=snitzer@redhat.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).