From patchwork Thu Feb 22 21:14:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 20825 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp213666dyb; Thu, 22 Feb 2024 13:14:27 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUwtuyh42YN5mBbLnbRS70ab27jVkKRF/pOn2RKkBYC7hUEF6F4YQEmw1fb1N0SDqDvFM83hsPxszMBJPIUZMICHKIHjQ== X-Google-Smtp-Source: AGHT+IFlk9oNgtekway+Lv87Aa+FlJaZkpctVkDboL2lSs16B5eG/0w01iqveMdck1ZRFET80QNs X-Received: by 2002:a05:6359:c8c:b0:176:b2af:9bf2 with SMTP id go12-20020a0563590c8c00b00176b2af9bf2mr23895787rwb.15.1708636467428; Thu, 22 Feb 2024 13:14:27 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708636467; cv=pass; d=google.com; s=arc-20160816; b=mP0+ej+Hf/w7neVH8YcRYG+hKfu9Co3rnWD16Lf+IY49cFKJlK7+dy2NHDKntk9u/r CKutFMjF8DfMHWab9Y0BNMvfQeSDCXALrdogTYDMF038sR/FmF6g8xmOG795bNSplXY3 q5ppPPw85LUUzqXltfKXbQm5DAO3Cvuof7JGgpAXPBAxWgwx+s397qDWi0eQd/lTOAba 1QI/x+DfeidYvLJoJsBUe9+4ldUbA2K53m9Ibeb4yydE+CYeDglUp0x91BZzNyKb7QHL yBKdeg8BE1epEDMNvKhNXClTWRKnzqcZF/xFu+FOtCLhXIlHHRU17F9/lW0VgwiI4MPG 21wQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-id:precedence:subject:cc:to :from:date:user-agent:message-id; bh=msfzntkOdMIElyNT/XQDXNdlqBVJ662EwYq+3CLapGI=; fh=6lU0d7+j2gvP0RlfbRyidxN6N8cP9012O+fDGzz+FVE=; b=eBklbbnhEA+HzA+/xVYNqsBZkbQHU/yiCX6yVnSiAXxgbxoL05Qlw+nl1qc2HvYh/q u3ySb1l/EX0JrVdbYY273YU9DPjK2b4594ob3bgQ2NkUoRXYsXY9NkDr5L3dBMcWnPwA EZST0ZOyoBiGl+ynMwKR87TX26ju9+dvjOlUSNbiI3h3oCSKqLy5be+ePJnPRyOtMw8T 9tVLE9Tn5jYTic4O/WWDCUaQRU6AVgRoJOoVZeDlSnEOSAEQ2SnjpJd/6GirX3hjYbMM V7vK0KNWghZqWaSmDWG40DSaqqATW3r8j7gLItKo+lNnrKHP/ELXxJAQUN7wroHJeMCH GpRw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-77375-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77375-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id s16-20020a639250000000b005dc3e73597dsi10820546pgn.293.2024.02.22.13.14.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 13:14:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-77375-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-77375-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77375-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 38F59283C4B for ; Thu, 22 Feb 2024 21:14:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B0E513BAE6; Thu, 22 Feb 2024 21:12:53 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDD0C73F30; Thu, 22 Feb 2024 21:12:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708636371; cv=none; b=qBHZUv/EiDLdd0hFyVrU2bOF2pPy6rXVV6wv95qs0IcP1ctKqM4P6hKFyRhYHvgLm+Gx51HiWWmyhi6MzI/p8M+4BtSMaW/L/z7metv72x+Qkvt10Dvx34bsYNxQJ5oQTjB3T0XGofKnx4SBwN+tzrfqeRmGIdQp7nDetND7ffs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708636371; c=relaxed/simple; bh=q2gN7JZMXEO4eGjTHjmn+gKip7svp7iLkDc5IBDr6N0=; h=Message-ID:Date:From:To:Cc:Subject; b=iu8wDECD0IRgxGB3eUHzM/xpR1nPPqntVuuWn/h4quvyIbhjXeeQrKgaXUsKbPSkyI+MQzjFYXVBYgHVCoPgOLeytw6BGBtiezRppg7+njMNgZcuvmO8A+J0FkYYbA15A00f/5kcrUuxxowLram5VLdPm4tcif6cc1iTsjrhnlY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71FC7C433F1; Thu, 22 Feb 2024 21:12:51 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.97) (envelope-from ) id 1rdGOw-00000006hpt-2X1q; Thu, 22 Feb 2024 16:14:42 -0500 Message-ID: <20240222211415.255659509@goodmis.org> User-Agent: quilt/0.67 Date: Thu, 22 Feb 2024 16:14:15 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= , Rodrigo Vivi , Chuck Lever Subject: [PATCH v2 0/4] tracing: Optimize __string()/__assign_str() processing Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791629932182150156 X-GMAIL-MSGID: 1791635192685920722 The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk("%s", __get_str(my_string)) There's even some code that may call a function helper to find the s->string value. The problem with the above is that the work to get the s->string is done twice. Once at the __string() and again in the __assign_str(). The length of the string is calculated via a strlen(), not once, but twice (using strcpy). The length is actually already recorded in the data location from __string() and here's no reason to call strcpy() in __assign_str() as the length is already known. The __string() macro uses dynamic_array() which has a helper structure that is created holding the offsets and length of the string fields. Instead of finding the string twice, just save it off in another field in that helper structure, and have __assign_str() use that instead. Changes since v1: https://lore.kernel.org/linux-trace-kernel/20240222195111.139824528@goodmis.org/ - Both the __dynamic_array() and __rel_dynamic_array() macros end with a semicolon and are used by __string() and __rel_string() respectively. But __string() doesn't have a semicolon after __dynamic_array() but __rel_string does have a semicolon after __rel_dynamic_array() which is unneeded. Remove the unnecessary semicolon to keep the two consistent. - Fixed __rel_string_len() that was incorrectly using __get_str() and not __get_rel_str(). - Added two cleanup patches. One to use the ?: shortcut and the other to use the new macro EVENT_NULL_STR instead of open coding "(null)" as the string must be consistent between __string() and __assign_str(). Steven Rostedt (Google) (4): tracing: Rework __assign_str() and __string() to not duplicate getting the string tracing: Do not calculate strlen() twice for __string() fields tracing: Use ? : shortcut in trace macros tracing: Use EVENT_NULL_STR macro instead of open coding "(null)" ---- include/linux/trace_events.h | 3 +++ include/trace/events/sunrpc.h | 12 ++++++------ include/trace/stages/stage2_data_offsets.h | 4 ++-- include/trace/stages/stage5_get_offsets.h | 15 ++++++++++----- include/trace/stages/stage6_event_callback.h | 12 ++++++++---- 5 files changed, 29 insertions(+), 17 deletions(-)