From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 C783A441A for ; Tue, 10 Oct 2023 03:46:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="RZopyhFg" Received: from out-192.mta0.migadu.com (out-192.mta0.migadu.com [91.218.175.192]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84F599E for ; Mon, 9 Oct 2023 20:46:20 -0700 (PDT) Message-ID: <7fbf47bf-c26c-8eeb-f803-b9f2bafa6364@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1696909578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hZJB97dQv1x5vY0R7LD94UsgnKYKd6vyN/0XXr9hYJc=; b=RZopyhFg1RxT0Rdep5vYxJJ7xzF+Ws3zGcvSAn7BpQ/kou3o3Xdg7a/J7bbR/e/YZWTP8F hpn4l064//3J3Gekd3Vhg+rG6BE31qI51cfsDXgAxxYAnPl0bsJ/tALlQo/u4ixpubQP1V 3f1baHkeF1EewyEU73MsCO508ivMyJ0= Date: Tue, 10 Oct 2023 11:46:08 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net-next v7] net/core: Introduce netdev_core_stats_inc() Content-Language: en-US To: Steven Rostedt Cc: Eric Dumazet , mhiramat@kernel.org, dennis@kernel.org, tj@kernel.org, cl@linux.com, mark.rutland@arm.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Lobakin , linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org References: <20231007050621.1706331-1-yajun.deng@linux.dev> <9f4fb613-d63f-9b86-fe92-11bf4dfb7275@linux.dev> <4a747fda-2bb9-4231-66d6-31306184eec2@linux.dev> <814b5598-5284-9558-8f56-12a6f7a67187@linux.dev> <508b33f7-3dc0-4536-21f6-4a5e7ade2b5c@linux.dev> <296ca17d-cff0-2d19-f620-eedab004ddde@linux.dev> <68eb65c5-1870-0776-0878-694a8b002a6d@linux.dev> <078f662d-a73f-766b-3a07-c82cd37026c5@linux.dev> <20231009102833.1b0d35e3@gandalf.local.home> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yajun Deng In-Reply-To: <20231009102833.1b0d35e3@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On 2023/10/9 22:28, Steven Rostedt wrote: > On Mon, 9 Oct 2023 18:58:27 +0800 > Yajun Deng wrote: > >>> C compiler decides to inline or not, depending on various factors. >>> >>> The most efficient (and small) code is generated by this_cpu_inc() >>> version, allowing the compiler to inline it. >>> >>> If you copy/paste this_cpu_inc() twenty times, then the compiler >>> would not inline the function anymore. > Yes, if you want something to be visible by ftrace, it must not be inlined > (as inlined functions are not function calls by definition). And as Eric > stated, the compiler is perfectly allowed to inline something if it > believes it will be more efficient. i.e. There may be code around the function > call that could be more efficient if it wasn't change to parameters. If you > want to make sure a function stays out of line, you must explicitly tell > the compiler you want the function not to ever be inlined (hence the > "noinline" attribute). Thanks for the details. >> >> Got it. Thank you. > Great. > > -- Steve