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 9F363C433EF for ; Thu, 19 May 2022 11:36:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237461AbiESLf7 (ORCPT ); Thu, 19 May 2022 07:35:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237452AbiESLfz (ORCPT ); Thu, 19 May 2022 07:35:55 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B228CDDE for ; Thu, 19 May 2022 04:35:51 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id w14so8543061lfl.13 for ; Thu, 19 May 2022 04:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openvz-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=oxibleWjg5piZBF2UIB37tPZ8A10UXKI4apmU+0ZgSE=; b=8EB4pJ5d6ls+vf8cvcPsR22q2RxCetm5Iw2kafSsbt/+95CKUc0uKp5QkBhyrST1rt 6lHoRg71vpeaZsk1OKWJUv5oDbc4vDrSGqQayY++4QB2v5fjP99+fSXmZImkVJclh3kD S1+iwmP44Yu9mSMNikOkMHFLdC3dG6TZF/UUW33LiEmsmu7kReeJyjxE4ExaolC+/IpH eH7yaRloZsgKADBBLdppr1XLrzBvtgj/QwFOf1FheHSdwvtFkYTpryFD3a22LKiRtgsl X3bN8EENiOaDuYZghe5I9Doa8KS82H/H0bFJUhUloRLebbtVRhn8zx7Rx4i4I3udKAvb vEVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=oxibleWjg5piZBF2UIB37tPZ8A10UXKI4apmU+0ZgSE=; b=DDipmUYK3/fgkl2TLerYKGIB8yF0y1PcwdiBSuWHkPUHkZ+LH2H7nqvH6x0BZgopxN eSdCrNMhqJiq8wGoW40CfhOlSpKfLUHQBejJCviAS+Qf/J0JSsS/lbGOhwuA3P3753/G IemrgUOmsFCI5bGozL00QYtqcBA+5JiJGOycPaFma+fThnMsLAgckXcV5kRWPqIyfbBV fEnQ84qYI66EbAMFm2WNTgBT9oKZGg80hTOYu//h4sTjzYC6Mfj2m1GfE8gw2PJDyrvy mT97+7LVKf5qcMeRDujfoaURHPQ7cwRuT6j2TOhIJ9ZQ9xwG3ZnSDrqVGoV1n4qBw0JL 6/tQ== X-Gm-Message-State: AOAM5335Zbi4PuPZeKroTwKTC2kSLDM2vyGXONPe2RdYid+ieylfhO0N FQZEtZeU4pryJFgSVEhpfFctXA== X-Google-Smtp-Source: ABdhPJyBQ4HZaR0d2ga1ci2zALQ/cTNDEyY0EG9kBXrlEqKR9WuzxRCVaJLz8zEcc0SL+lFTe1PQeA== X-Received: by 2002:a05:6512:686:b0:473:9d94:372d with SMTP id t6-20020a056512068600b004739d94372dmr3000734lfe.623.1652960150032; Thu, 19 May 2022 04:35:50 -0700 (PDT) Received: from [192.168.43.196] ([185.174.128.243]) by smtp.gmail.com with ESMTPSA id j5-20020ac253a5000000b0047255d21163sm260922lfh.146.2022.05.19.04.35.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 May 2022 04:35:49 -0700 (PDT) Message-ID: Date: Thu, 19 May 2022 14:35:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v3] tracing: add 'accounted' entry into output of allocation tracepoints Content-Language: en-US To: Steven Rostedt 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 References: <20220518160447.20a7b96f@gandalf.local.home> From: Vasily Averin In-Reply-To: <20220518160447.20a7b96f@gandalf.local.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/18/22 23:04, Steven Rostedt wrote: > On Wed, 18 May 2022 09:24:51 +0300 > Vasily Averin wrote: > > FYI, the subject should be something like: mm/tracing: > Because "tracing:" is reserved for tracing infrastructure updates. Thank you for noticing. >> @@ -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? Thank you, Vasily Averin