Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3803096pxj; Mon, 21 Jun 2021 07:00:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPnLCLq+9TteqIEhpAR51AlPLocB0ImjNvWIRle+NAR7ReAgv4nhww/V5QFCAFiazA7EV/ X-Received: by 2002:a05:6e02:20cb:: with SMTP id 11mr17208138ilq.132.1624284058182; Mon, 21 Jun 2021 07:00:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624284058; cv=none; d=google.com; s=arc-20160816; b=D9k2NLYvMWfxfHPJ7pJ8D3aWnE5nIbzuXDsnnvvY+gHzr5N3YtrmMFUwLGArTseTeI 6xV9RGVCBJ/0hpSRJhuWN8JQefeQGAdXGrZGX4Hiw/jWUQzczX0HaC3cp0weAFjqd+b8 ORdYMFLXgu6k7pdM3sQWxrDO6AFLeRxBTOaJks0h/svcXj5rkYTOgrcq6JOB2JRDusw+ TFptKP4kQU6fC7TKGEo5rt2YrO5XI3f62IAtdY+K3E1B2F+OxrJOZtj9ob/oS28WX/Pe QIGXYxAR5W2LQdSiIJqIvjiQwuUE7WMPEEhCxVIdfm4228Z9T0enygoFbFTRvN3O0mVA Q6zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=OPHV4FkxMpdcPEu4QRleeY23htouayhVcp3Csc9wJxg=; b=x0YnNkzs/hv+Mskxs7zGng5RIGUyGgU0npZfHF7qt1yP+/iXWesXUtCLKL9gP1Ohar okci5I5DYBxKjWTYoZl5CdneGUuOsLlGb9V00nvFz2EmV3CMvnmdWS6Ht+zW0Ale+1Bx RKcxlIdPm+MxbUFd0E2Y4ooZnRlHp3/8aApUMLEqya2oWAbcCfUdddLML+y4i19r/zz7 npLgHfvVBUJq8GSrTM+9RtzJbLMjY3DBf6l6HkN8INzVDyqNiJaSKX09mBc7qZWQUTac MXltX4EgEd64Q7T2CWTmoUYN4sm8HYma0YtURuB+Eq7jilBo4/gqjq6rIhZ4Kaw+fvha 2z3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y5si20442493ioq.102.2021.06.21.07.00.44; Mon, 21 Jun 2021 07:00:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229897AbhFUOCV (ORCPT + 99 others); Mon, 21 Jun 2021 10:02:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:57306 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbhFUOCU (ORCPT ); Mon, 21 Jun 2021 10:02:20 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 099646120D; Mon, 21 Jun 2021 14:00:05 +0000 (UTC) Date: Mon, 21 Jun 2021 10:00:04 -0400 From: Steven Rostedt To: Tiezhu Yang Cc: Ingo Molnar , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Xuefeng Li Subject: Re: [RFC PATCH 1/2] ftrace: Introduce cmdline argument ftrace_disabled Message-ID: <20210621100004.7c1505be@oasis.local.home> In-Reply-To: <6847bf76-698d-a314-0825-803b48cb8740@loongson.cn> References: <1624084160-3342-1-git-send-email-yangtiezhu@loongson.cn> <1624084160-3342-2-git-send-email-yangtiezhu@loongson.cn> <20210619112202.0a2c7196@gandalf.local.home> <6847bf76-698d-a314-0825-803b48cb8740@loongson.cn> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 Jun 2021 09:21:31 +0800 Tiezhu Yang wrote: > > > > You have no rationale for this change. What's the purpose of this? > > The "System Benchmarks Index Score" of UnixBench under FUNCTION_TRACER > is lower than !FUNCTION_TRACER, I want to use this new cmdline argument > ftrace_disabled to test it, this is the original intention. > > I see the following help info of "config FUNCTION_TRACER": > > [If it's runtime disabled (the bootup default), then the overhead of the > instructions is very small and not measurable even in micro-benchmarks.] Those benchmarks were done a long time ago, and they may be measurable today :-/ > > I am not quite understand the above description, could you tell me how to > avoid the runtime performance overhead under FUNCTION_TRACER? Anyway, your patch wont do anything to change the benchmarks. When CONFIG_FUNCTION_TRACER is enabled, on x86_64, most functions will start with a call to fentry. At boot up, these functions will be converted over to become a nop. And thinking about it, "ftrace_disable" stops all conversions, so if you add that to the kernel command line, those calls to fentry, wont be converted to nops, and you'll make things much worse! Now, some versions of gcc (and perhaps clang) can do the conversion to nops at compile time (in which case, your patch would keep the nops and not the calls to fentry). The overhead that FUNCTION_TRACER adds is the 5 byte nop at the start of most functions. This causes a slight hit to instruction cache, and a minuscule amount of time in the instruction pipeline of the CPU. This is the "overhead" that is talked about. Your patch doesn't do anything to address it. The only way to remove that overhead is to compile the kernel without CONFIG_FUNCTION_TRACER. -- Steve