[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180122160437.4kct2cz2ihwymvct@linux-x5ow.site>
Date: Mon, 22 Jan 2018 17:04:37 +0100
From: Johannes Thumshirn <jthumshirn@...e.de>
To: Christoph Hellwig <hch@....de>
Cc: Sagi Grimberg <sagi@...mberg.me>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
Linux NVMe Mailinglist <linux-nvme@...ts.infradead.org>,
Keith Busch <keith.busch@...el.com>,
Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH v4 1/2] nvme: add tracepoint for nvme_setup_cmd
On Mon, Jan 22, 2018 at 04:59:56PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 22, 2018 at 04:53:56PM +0100, Johannes Thumshirn wrote:
> > Yes and no. I personally like to have the big hammer when tracing customer
> > problems and filter out maunally later. I initially had a tracepoint for each
> > of nvme_setup_flush(), nvme_setup_discard(), nvme_setup_rw() but decided it
> > was too fine grained.
> >
> > nvme_setup_cmd() has the nice side effect that all commands, including
> > userspace passtrough commands must pass it. This was extremely helpful in the
> > customer bug which inspired me to implement this tracepoint.
>
> Not arguing against placing the tracepoint(s) in nvme_setup_cmd, but
> it seems like we should have one for admin and one for I/O commands.
> Especially as we have to special case them just about everywhere,
> and the overlap of the opcode space is pretty annoying.
You mean like:
if (ns)
trace_nvme_setup_cmd(cmd);
else
trace_nvme_setup_admin_cmd(cmd);
?
--
Johannes Thumshirn Storage
jthumshirn@...e.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Powered by blists - more mailing lists