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 2A68AC433EF for ; Thu, 19 May 2022 16:29:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242018AbiESQ3o (ORCPT ); Thu, 19 May 2022 12:29:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241017AbiESQ3l (ORCPT ); Thu, 19 May 2022 12:29:41 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39712D4137 for ; Thu, 19 May 2022 09:29:40 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id u7so6156635ljd.11 for ; Thu, 19 May 2022 09:29:40 -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=hfE6dx+3G7Xhg3fy//ddTC1qoRqj08jbiWPXg96CPJQ=; b=rE0GDgG3Pt5dENINhb/kwvh/Pk69bR4+ep8u3JTbELATCir4elLVBe7ACfHSa9J/Xr Yy5cAs9KADlL439mw4LWNreCKNwmqzWvhxyIotrdVRBMjtb7QSz6aPVMg5XJ0AQvM0E9 I388He++d+4oUsZDpchg0LM4rUE/uU60u3UimmQCZJujwBah/TXew3VXWWtj6AF/iCQF fidgCcCLX/RkNaehXoFzb0/rv6mo7Arj+cNKKV7PmUzAfTq6zINL2IAC1i3Zq2pXBV5y YT6WiXvjSVHbcBMOCfbh5SH4lQl+NdtW38ns+MrXjwc+BGAmXkBmXGxrYii1g6OlcRcA Pp6A== 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=hfE6dx+3G7Xhg3fy//ddTC1qoRqj08jbiWPXg96CPJQ=; b=cME81ARQLDlLdYyA9EsRKefnQ4bxfVtpOgKTJOdkkYY50YNwsd6QeCjACBK5b71mz2 32sxGi+1QEwZKzeSO61BNrt5Q2f3o3XmZbijYNaol0E8m3Foi2ubVa46ANh4J4djrOaM x/5N/TKKTSo59jsCku1PRbu6CftxCQRBAdQIK9bvvmrZUVhyg61qOskQS2scHTafQqqF a6oqQ4MefM/l1xFe97c3/WUttUXpqN2wn+fOtGt1UnSPdT7VYFAD9J+Yu62hyjY/fpNK qZ3ncsafOhU14eFgIW7hbjVA8pi1+TWE2rpQqpzGSBZpR7KQ8er9iP9QKvr4UtoWoyzo /AOw== X-Gm-Message-State: AOAM532YWMaYQQkPeXwYznm9czkr3TcPWcv1ocZFXQuuT/5KlaVPorUA 2NO10hqD3MXI1N5OwKgGfE0qqw== X-Google-Smtp-Source: ABdhPJxGirHOdCIW97ARJn+QNyyJ8XqYYnMMhx5NlIeuy1e5/tqxYqZ13Mdoe3BHU/DnIuuUJao5dg== X-Received: by 2002:a2e:7308:0:b0:253:cd16:a893 with SMTP id o8-20020a2e7308000000b00253cd16a893mr3110782ljc.259.1652977778546; Thu, 19 May 2022 09:29:38 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.185]) by smtp.gmail.com with ESMTPSA id z2-20020a2e9b82000000b00253cd476074sm527503lji.111.2022.05.19.09.29.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 May 2022 09:29:38 -0700 (PDT) Message-ID: Date: Thu, 19 May 2022 19:29:36 +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> <20220519100348.101d027d@gandalf.local.home> From: Vasily Averin In-Reply-To: <20220519100348.101d027d@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/19/22 17:03, Steven Rostedt wrote: > 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. Frankly speaking I vote for performance with both hands. However I'm still would like to avoid new sparse warnings. Christoph Hellwig just recently taught me, "never add '__force' before thinking hard about them", but in this case I would need to use it three times. I found that bitwise typecasts can be avoided by using translation unions. What do you think about following trick? diff --git a/mm/slab.h b/mm/slab.h index 95eb34174c1b..f676612ca40f 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -882,4 +882,14 @@ void __check_heap_object(const void *ptr, unsigned long n, } #endif +union gfp_flags_u { + unsigned long ulong; + gfp_t flags; +}; + +union slab_flags_u { + unsigned int uint; + slab_flags_t sflags; +}; + #endif /* MM_SLAB_H */ diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h index 71c141804222..91632a61e16d 100644 --- a/include/trace/events/kmem.h +++ b/include/trace/events/kmem.h @@ -13,18 +13,20 @@ DECLARE_EVENT_CLASS(kmem_alloc, TP_PROTO(unsigned long call_site, const void *ptr, + struct kmem_cache *s, size_t bytes_req, size_t bytes_alloc, gfp_t gfp_flags), - TP_ARGS(call_site, ptr, bytes_req, bytes_alloc, gfp_flags), + TP_ARGS(call_site, ptr, s, bytes_req, bytes_alloc, gfp_flags), TP_STRUCT__entry( __field( unsigned long, call_site ) __field( const void *, ptr ) __field( size_t, bytes_req ) __field( size_t, bytes_alloc ) - __field( unsigned long, gfp_flags ) + __field_struct( union gfp_flags_u, gfp ) + __field_struct( union slab_flags_u, s ) ), TP_fast_assign( @@ -32,51 +34,57 @@ DECLARE_EVENT_CLASS(kmem_alloc, __entry->ptr = ptr; __entry->bytes_req = bytes_req; __entry->bytes_alloc = bytes_alloc; - __entry->gfp_flags = (__force unsigned long)gfp_flags; + __entry->gfp.flags = gfp_flags; + __entry->s.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.ulong), + ((__entry->gfp.flags & __GFP_ACCOUNT) || + (__entry->s.sflags & SLAB_ACCOUNT)) ? "true" : "false") ); Thank you, Vasily Averin 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 E48B4C433FE for ; Thu, 19 May 2022 16:29:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E90D6B0071; Thu, 19 May 2022 12:29:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1990D6B0072; Thu, 19 May 2022 12:29:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 038D76B0073; Thu, 19 May 2022 12:29:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E249B6B0071 for ; Thu, 19 May 2022 12:29:46 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AD53032862 for ; Thu, 19 May 2022 16:29:46 +0000 (UTC) X-FDA: 79483028772.17.B90EA2A Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf05.hostedemail.com (Postfix) with ESMTP id ABF0910000C for ; Thu, 19 May 2022 16:29:20 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id i23so6871375ljb.4 for ; Thu, 19 May 2022 09:29:44 -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=hfE6dx+3G7Xhg3fy//ddTC1qoRqj08jbiWPXg96CPJQ=; b=rE0GDgG3Pt5dENINhb/kwvh/Pk69bR4+ep8u3JTbELATCir4elLVBe7ACfHSa9J/Xr Yy5cAs9KADlL439mw4LWNreCKNwmqzWvhxyIotrdVRBMjtb7QSz6aPVMg5XJ0AQvM0E9 I388He++d+4oUsZDpchg0LM4rUE/uU60u3UimmQCZJujwBah/TXew3VXWWtj6AF/iCQF fidgCcCLX/RkNaehXoFzb0/rv6mo7Arj+cNKKV7PmUzAfTq6zINL2IAC1i3Zq2pXBV5y YT6WiXvjSVHbcBMOCfbh5SH4lQl+NdtW38ns+MrXjwc+BGAmXkBmXGxrYii1g6OlcRcA Pp6A== 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=hfE6dx+3G7Xhg3fy//ddTC1qoRqj08jbiWPXg96CPJQ=; b=c196SfsyURnXiINdmX+cpgz1Ddiue8d4QYJmI+w6XcIcfcDlApttEcceRXwCCyEfcP OKaf3P89oVQvrgN0YswvXAJVLb5/RuyVYkYHZ0yUjqSh1UzxN4vQySUFqk0gNUii3ts0 e2JTaWVbOnOVEa23jquixOfkFQJPI0vu6/bgd3Atejv+0+ov1bvEqWAdXaVTBPMGj97F d8/HNdcYKfsd06i50PV/P5P4Z+GEFuhLQJZ6fIS46Yt1NRG98cY/DsUSOlPLg7IKW2C7 FRJa4wLetdjvUvqV3IUAB8hza9VKcX4pGDcfPdcig8dZ8g7Meg3+7hiVfU5SnCbWrjav 6fVw== X-Gm-Message-State: AOAM5335o7Q2NuU+fDANX2OHUcd+FxGcNXn2uvXN1mKrmAxexjz/Xfss L2Fikn014UdmwX/2BGwUnKY7JA== X-Google-Smtp-Source: ABdhPJxGirHOdCIW97ARJn+QNyyJ8XqYYnMMhx5NlIeuy1e5/tqxYqZ13Mdoe3BHU/DnIuuUJao5dg== X-Received: by 2002:a2e:7308:0:b0:253:cd16:a893 with SMTP id o8-20020a2e7308000000b00253cd16a893mr3110782ljc.259.1652977778546; Thu, 19 May 2022 09:29:38 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.185]) by smtp.gmail.com with ESMTPSA id z2-20020a2e9b82000000b00253cd476074sm527503lji.111.2022.05.19.09.29.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 May 2022 09:29:38 -0700 (PDT) Message-ID: Date: Thu, 19 May 2022 19:29:36 +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.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 References: <20220518160447.20a7b96f@gandalf.local.home> <20220519100348.101d027d@gandalf.local.home> From: Vasily Averin In-Reply-To: <20220519100348.101d027d@gandalf.local.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: j3w7gj8wn851i9kkmcunkrwp6qnhsur6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: ABF0910000C X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=rE0GDgG3; dmarc=pass (policy=none) header.from=openvz.org; spf=pass (imf05.hostedemail.com: domain of vvs@openvz.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=vvs@openvz.org X-HE-Tag: 1652977760-528626 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 5/19/22 17:03, Steven Rostedt wrote: > 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. Frankly speaking I vote for performance with both hands. However I'm still would like to avoid new sparse warnings. Christoph Hellwig just recently taught me, "never add '__force' before thinking hard about them", but in this case I would need to use it three times. I found that bitwise typecasts can be avoided by using translation unions. What do you think about following trick? diff --git a/mm/slab.h b/mm/slab.h index 95eb34174c1b..f676612ca40f 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -882,4 +882,14 @@ void __check_heap_object(const void *ptr, unsigned long n, } #endif +union gfp_flags_u { + unsigned long ulong; + gfp_t flags; +}; + +union slab_flags_u { + unsigned int uint; + slab_flags_t sflags; +}; + #endif /* MM_SLAB_H */ diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h index 71c141804222..91632a61e16d 100644 --- a/include/trace/events/kmem.h +++ b/include/trace/events/kmem.h @@ -13,18 +13,20 @@ DECLARE_EVENT_CLASS(kmem_alloc, TP_PROTO(unsigned long call_site, const void *ptr, + struct kmem_cache *s, size_t bytes_req, size_t bytes_alloc, gfp_t gfp_flags), - TP_ARGS(call_site, ptr, bytes_req, bytes_alloc, gfp_flags), + TP_ARGS(call_site, ptr, s, bytes_req, bytes_alloc, gfp_flags), TP_STRUCT__entry( __field( unsigned long, call_site ) __field( const void *, ptr ) __field( size_t, bytes_req ) __field( size_t, bytes_alloc ) - __field( unsigned long, gfp_flags ) + __field_struct( union gfp_flags_u, gfp ) + __field_struct( union slab_flags_u, s ) ), TP_fast_assign( @@ -32,51 +34,57 @@ DECLARE_EVENT_CLASS(kmem_alloc, __entry->ptr = ptr; __entry->bytes_req = bytes_req; __entry->bytes_alloc = bytes_alloc; - __entry->gfp_flags = (__force unsigned long)gfp_flags; + __entry->gfp.flags = gfp_flags; + __entry->s.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.ulong), + ((__entry->gfp.flags & __GFP_ACCOUNT) || + (__entry->s.sflags & SLAB_ACCOUNT)) ? "true" : "false") ); Thank you, Vasily Averin