From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55319C433F5 for ; Thu, 19 May 2022 14:03:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239053AbiESOD5 (ORCPT ); Thu, 19 May 2022 10:03:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238688AbiESODy (ORCPT ); Thu, 19 May 2022 10:03:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 359D438AB for ; Thu, 19 May 2022 07:03:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C6AF4618A8; Thu, 19 May 2022 14:03:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A09DC385AA; Thu, 19 May 2022 14:03:50 +0000 (UTC) Date: Thu, 19 May 2022 10:03:48 -0400 From: Steven Rostedt To: Vasily Averin Cc: YoPOhRctb8wwbmY5@carbon, Shakeel Butt , Roman Gushchin , Vlastimil Babka , Matthew Wilcox , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Muchun Song , kernel@openvz.org, linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , linux-mm@kvack.org, Joonsoo Kim , David Rientjes , Pekka Enberg , Christoph Lameter , Michal Hocko Subject: Re: [PATCH v3] tracing: add 'accounted' entry into output of allocation tracepoints Message-ID: <20220519100348.101d027d@gandalf.local.home> In-Reply-To: References: <20220518160447.20a7b96f@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (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 Thu, 19 May 2022 14:35:46 +0300 Vasily Averin wrote: > >> @@ -33,42 +35,46 @@ DECLARE_EVENT_CLASS(kmem_alloc, > >> __entry->bytes_req = bytes_req; > >> __entry->bytes_alloc = bytes_alloc; > >> __entry->gfp_flags = (__force unsigned long)gfp_flags; > >> + __entry->accounted = (gfp_flags & __GFP_ACCOUNT) || > >> + (s && s->flags & SLAB_ACCOUNT); > > > > Now you could make this even faster in the fast path and save just the > > s->flags. > > > > __entry->sflags = s ? s->flags : 0; > > > >> ), > >> > >> - TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s", > >> + TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s accounted=%s", > >> (void *)__entry->call_site, > >> __entry->ptr, > >> __entry->bytes_req, > >> __entry->bytes_alloc, > >> - show_gfp_flags(__entry->gfp_flags)) > >> + show_gfp_flags(__entry->gfp_flags), > >> + __entry->accounted ? "true" : "false") > > > > And then have: "accounted=%s": > > > > (__entry->gfp_flags & __GFP_ACCOUNT) || > > (__entry->sflags & SLAB_ACCOUNT) ? "true" : "false" > > Unfortunately this returns back sparse warnings about bitwise gfp_t and slab_flags_t casts. > Could you please explain why your variant is faster? Micro-optimization, grant you, but it is faster because it moves some of the logic into the slow path (the read side), and takes it out of the fast path (the write side). The idea of tracing is to squeeze out every cycle we can to keep the tracing overhead down. But it's really up to you if you need that. I'm not going to let this be a blocker. This is more of an FYI than anything else. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40F8EC433F5 for ; Thu, 19 May 2022 14:03:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A32926B0071; Thu, 19 May 2022 10:03:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BCD96B0073; Thu, 19 May 2022 10:03:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85DEC6B0074; Thu, 19 May 2022 10:03:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 76DD56B0071 for ; Thu, 19 May 2022 10:03:54 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 52492336D7 for ; Thu, 19 May 2022 14:03:54 +0000 (UTC) X-FDA: 79482661188.13.16F826C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id D3B95400CB for ; Thu, 19 May 2022 14:03:50 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C2449618A6; Thu, 19 May 2022 14:03:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A09DC385AA; Thu, 19 May 2022 14:03:50 +0000 (UTC) Date: Thu, 19 May 2022 10:03:48 -0400 From: Steven Rostedt To: Vasily Averin Cc: YoPOhRctb8wwbmY5@carbon.kvack.org, Shakeel Butt , Roman Gushchin , Vlastimil Babka , Matthew Wilcox , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Muchun Song , kernel@openvz.org, linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , linux-mm@kvack.org, Joonsoo Kim , David Rientjes , Pekka Enberg , Christoph Lameter , Michal Hocko Subject: Re: [PATCH v3] tracing: add 'accounted' entry into output of allocation tracepoints Message-ID: <20220519100348.101d027d@gandalf.local.home> In-Reply-To: References: <20220518160447.20a7b96f@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D3B95400CB Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=wKKC=V3=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=wKKC=V3=goodmis.org=rostedt@kernel.org"; dmarc=none X-Rspam-User: X-Stat-Signature: fb8tq6f5p9iet6fdd333dunzmdb57tox X-HE-Tag: 1652969030-169613 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 19 May 2022 14:35:46 +0300 Vasily Averin wrote: > >> @@ -33,42 +35,46 @@ DECLARE_EVENT_CLASS(kmem_alloc, > >> __entry->bytes_req = bytes_req; > >> __entry->bytes_alloc = bytes_alloc; > >> __entry->gfp_flags = (__force unsigned long)gfp_flags; > >> + __entry->accounted = (gfp_flags & __GFP_ACCOUNT) || > >> + (s && s->flags & SLAB_ACCOUNT); > > > > Now you could make this even faster in the fast path and save just the > > s->flags. > > > > __entry->sflags = s ? s->flags : 0; > > > >> ), > >> > >> - TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s", > >> + TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s accounted=%s", > >> (void *)__entry->call_site, > >> __entry->ptr, > >> __entry->bytes_req, > >> __entry->bytes_alloc, > >> - show_gfp_flags(__entry->gfp_flags)) > >> + show_gfp_flags(__entry->gfp_flags), > >> + __entry->accounted ? "true" : "false") > > > > And then have: "accounted=%s": > > > > (__entry->gfp_flags & __GFP_ACCOUNT) || > > (__entry->sflags & SLAB_ACCOUNT) ? "true" : "false" > > Unfortunately this returns back sparse warnings about bitwise gfp_t and slab_flags_t casts. > Could you please explain why your variant is faster? Micro-optimization, grant you, but it is faster because it moves some of the logic into the slow path (the read side), and takes it out of the fast path (the write side). The idea of tracing is to squeeze out every cycle we can to keep the tracing overhead down. But it's really up to you if you need that. I'm not going to let this be a blocker. This is more of an FYI than anything else. -- Steve