Received: by 10.192.165.156 with SMTP id m28csp779363imm; Fri, 13 Apr 2018 07:42:57 -0700 (PDT) X-Google-Smtp-Source: AIpwx48FLBJGzewUtagSKwvXUxcdpLea/aeVYz9IAevflY2HQ7C/Fd/GCagr6iNJT5L4GFtpYPU9 X-Received: by 10.98.171.7 with SMTP id p7mr11751089pff.215.1523630577798; Fri, 13 Apr 2018 07:42:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523630577; cv=none; d=google.com; s=arc-20160816; b=LM7ddiJZfdZVoA87DbUiGJdOznoZqN2BmCwGfHfGNXSZU1obo13CW/X0daT9QYf6BM qDTPKxXYLwcpCmb8xWmiHKyb/7XwW0iD3voO192o4FxlFbRrbMuZPEf/yhbakMJoezc/ f8nKF9P7sGofI0nTFHlduPTlpQjtUgRruFo1SPjHtaKYlaWde45rTZ3h2LP77+yDKn7L wYEbVkWdDtK24r9o+FOv1NW4DFU/eVU+6M7ySfLJPcu+5yngxeZDk0vfY9GPGqNOe7u7 OU5bCnHfuiLv+9ifaRbMkdGEsDTafU1LiQNFdm6ThC5qAi2Db3Xe5Y0lYjdjZ3lE0ePr iuXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:references:in-reply-to:date :subject:cc:to:from:arc-authentication-results; bh=XUCGLu7VgPhYFZjFy+Hh6t/oASScTF1JoyQKBHkEkdg=; b=lrCte6CtqWd2NbBYZRop9ftZEuj3eFJprKbfmHtNyLXIQy7fxq7+FzB6W2S83VOyYH m6SDUlZ9QcFqoRkhXqc0xnMa4vyaB0tKKobV7t1DIebspBLqXM9gXFdMe0tLcpXa9SST IcW9piXquMz6cAIx3s+lRvyG9VRliRNH2ZHIOZq6Sn1Ir/ZZ4uNbcKo40st6tfxNWaok O5vGDdAqFG4DOBMVYquIN5AphdGq4UHpARQrVSDv9qMqdHqeBNSXOBCUH/SJj0KM5Q66 Hm9ROudUf7a0bVkBR09fFFYlUkeD/QDeth+Qvy9vwd4MYlOOMAIoRFrqcZFCjOaIZC6e 8eHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t190si4187989pgb.409.2018.04.13.07.42.41; Fri, 13 Apr 2018 07:42:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754154AbeDMNIU (ORCPT + 99 others); Fri, 13 Apr 2018 09:08:20 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50506 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753985AbeDMNIR (ORCPT ); Fri, 13 Apr 2018 09:08:17 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3DD4TFm003915 for ; Fri, 13 Apr 2018 09:08:17 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2havvf10ym-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Fri, 13 Apr 2018 09:08:16 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Apr 2018 14:08:14 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 13 Apr 2018 14:08:10 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w3DD89o18978874; Fri, 13 Apr 2018 13:08:09 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A7CA552047; Fri, 13 Apr 2018 12:59:04 +0100 (BST) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id 6922C52041; Fri, 13 Apr 2018 12:59:04 +0100 (BST) From: Steffen Maier To: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org Cc: Steven Rostedt , Ingo Molnar , Jens Axboe , Li Zefan , Greg Kroah-Hartman , Steffen Maier Subject: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events Date: Fri, 13 Apr 2018 15:07:18 +0200 X-Mailer: git-send-email 2.13.5 In-Reply-To: <20180413130719.22921-1-maier@linux.ibm.com> References: <20180413130719.22921-1-maier@linux.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 18041313-0044-0000-0000-00000546EEA6 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18041313-0045-0000-0000-000028872E75 Message-Id: <20180413130719.22921-3-maier@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-13_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1804130122 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block trace points to TRACE_EVENT()") to be equivalent to traditional blktrace output. Also this allows event filtering to not always get all (un)plug events. NB: The NULL pointer check for q->kobj.parent is certainly racy and I don't have enough experience if it's good enough for a trace event. The change did work for my cases (block device read/write I/O on zfcp-attached SCSI disks and dm-mpath on top). While I haven't seen any prior art using driver core (parent) relations for trace events, there are other cases using this when no direct pointer exists between objects, such as: #define to_scsi_target(d) container_of(d, struct scsi_target, dev) static inline struct scsi_target *scsi_target(struct scsi_device *sdev) { return to_scsi_target(sdev->sdev_gendev.parent); } This is the object model we make use of here: struct gendisk { struct hd_struct { struct device { /*container_of*/ struct kobject kobj; <--+ dev_t devt; /*deref*/ | } __dev; | } part0; | struct request_queue *queue; ..+ | } : | : | struct request_queue { <..............+ | /* queue kobject */ | struct kobject { | struct kobject *parent; --------+ } kobj; } The parent pointer comes from: #define disk_to_dev(disk) (&(disk)->part0.__dev) int blk_register_queue(struct gendisk *disk) struct device *dev = disk_to_dev(disk); struct request_queue *q = disk->queue; ret = kobject_add(&q->kobj, kobject_get(&dev->kobj), "%s", "queue"); ^^^parent $ ls -d /sys/block/sdf/queue /sys/block/sda/queue $ cat /sys/block/sdf/dev 80:0 A partition does not have its own request queue: $ cat /sys/block/sdf/sdf1/dev 8:81 $ ls -d /sys/block/sdf/sdf1/queue ls: cannot access '/sys/block/sdf/sdf1/queue': No such file or directory The difference to blktrace parsed output is that block events don't use the partition's minor number but the containing block device's minor number: $ dd if=/dev/sdf1 count=1 $ cat /sys/kernel/debug/tracing/trace block_bio_remap: 8,80 R 2048 + 32 <- (8,81) 0 block_bio_queue: 8,80 R 2048 + 32 [dd] block_getrq: 8,80 R 2048 + 32 [dd] block_plug: 8,80 [dd] ^^^^ block_rq_insert: 8,80 R 16384 () 2048 + 32 [dd] block_unplug: 8,80 [dd] 1 explicit ^^^^ block_rq_issue: 8,80 R 16384 () 2048 + 32 [dd] block_rq_complete: 8,80 R () 2048 + 32 [0] $ btrace /dev/sdf1 8,80 1 1 0.000000000 240240 A R 2048 + 32 <- (8,81) 0 8,81 1 2 0.000220890 240240 Q R 2048 + 32 [dd] 8,81 1 3 0.000229639 240240 G R 2048 + 32 [dd] 8,81 1 4 0.000231805 240240 P N [dd] ^^ 8,81 1 5 0.000234671 240240 I R 2048 + 32 [dd] 8,81 1 6 0.000236365 240240 U N [dd] 1 ^^ 8,81 1 7 0.000238527 240240 D R 2048 + 32 [dd] 8,81 2 2 0.000613741 0 C R 2048 + 32 [0] Signed-off-by: Steffen Maier --- include/trace/events/block.h | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/include/trace/events/block.h b/include/trace/events/block.h index a13613d27cee..cffedc26e8a3 100644 --- a/include/trace/events/block.h +++ b/include/trace/events/block.h @@ -460,14 +460,18 @@ TRACE_EVENT(block_plug, TP_ARGS(q), TP_STRUCT__entry( + __field( dev_t, dev ) __array( char, comm, TASK_COMM_LEN ) ), TP_fast_assign( + __entry->dev = q->kobj.parent ? + container_of(q->kobj.parent, struct device, kobj)->devt : 0; memcpy(__entry->comm, current->comm, TASK_COMM_LEN); ), - TP_printk("[%s]", __entry->comm) + TP_printk("%d,%d [%s]", + MAJOR(__entry->dev), MINOR(__entry->dev), __entry->comm) ); #define show_block_unplug_explicit(val) \ @@ -482,18 +486,23 @@ DECLARE_EVENT_CLASS(block_unplug, TP_ARGS(q, depth, explicit), TP_STRUCT__entry( + __field( dev_t, dev ) __field( int, nr_rq ) __field( bool, explicit ) __array( char, comm, TASK_COMM_LEN ) ), TP_fast_assign( + __entry->dev = q->kobj.parent ? + container_of(q->kobj.parent, struct device, kobj)->devt : 0; __entry->nr_rq = depth; __entry->explicit = explicit; memcpy(__entry->comm, current->comm, TASK_COMM_LEN); ), - TP_printk("[%s] %d %s", __entry->comm, __entry->nr_rq, + TP_printk("%d,%d [%s] %d %s", + MAJOR(__entry->dev), MINOR(__entry->dev), + __entry->comm, __entry->nr_rq, show_block_unplug_explicit(__entry->explicit)) ); -- 2.13.5