All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <willy@infradead.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>
Subject: Re: [PATCH v2 1/7] mm: vmalloc: Add alloc_vmap_area trace event
Date: Mon, 14 Nov 2022 17:55:06 +0100	[thread overview]
Message-ID: <Y3Jy6rSAiHco5q7v@pc636> (raw)
In-Reply-To: <20221114105325.57d27b6f@gandalf.local.home>

> On Tue, 18 Oct 2022 20:10:47 +0200
> "Uladzislau Rezki (Sony)" <urezki@gmail.com> wrote:
> 
> > It is for a debug purpose and for validation of passed parameters.
> > 
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > ---
> >  include/trace/events/vmalloc.h | 56 ++++++++++++++++++++++++++++++++++
> >  1 file changed, 56 insertions(+)
> >  create mode 100644 include/trace/events/vmalloc.h
> > 
> > diff --git a/include/trace/events/vmalloc.h b/include/trace/events/vmalloc.h
> > new file mode 100644
> > index 000000000000..39fbd77c91e7
> > --- /dev/null
> > +++ b/include/trace/events/vmalloc.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#undef TRACE_SYSTEM
> > +#define TRACE_SYSTEM vmalloc
> > +
> > +#if !defined(_TRACE_VMALLOC_H) || defined(TRACE_HEADER_MULTI_READ)
> > +#define _TRACE_VMALLOC_H
> > +
> > +#include <linux/tracepoint.h>
> > +
> > +/**
> > + * alloc_vmap_area - called when a new vmap allocation occurs
> > + * @addr:	an allocated address
> > + * @size:	a requested size
> > + * @align:	a requested alignment
> > + * @vstart:	a requested start range
> > + * @vend:	a requested end range
> > + * @failed:	an allocation failed or not
> > + *
> > + * This event is used for a debug purpose, it can give an extra
> > + * information for a developer about how often it occurs and which
> > + * parameters are passed for further validation.
> > + */
> > +TRACE_EVENT(alloc_vmap_area,
> > +
> > +	TP_PROTO(unsigned long addr, unsigned long size, unsigned long align,
> > +		unsigned long vstart, unsigned long vend, int failed),
> > +
> > +	TP_ARGS(addr, size, align, vstart, vend, failed),
> 
> The above is passed in via (from patch 4):
> 
> 
> @@ -1621,6 +1624,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>  		size, align, vstart, vend);
>  	spin_unlock(&free_vmap_area_lock);
>  
> +	trace_alloc_vmap_area(addr, size, align, vstart, vend, addr == vend);
> +
>  	/*
>  	 * If an allocation fails, the "vend" address is
>  	 * returned. Therefore trigger the overflow path.
> 
> > +
> > +	TP_STRUCT__entry(
> > +		__field(unsigned long, addr)
> > +		__field(unsigned long, size)
> > +		__field(unsigned long, align)
> > +		__field(unsigned long, vstart)
> > +		__field(unsigned long, vend)
> 
> > +		__field(int, failed)
> 
> I would drop the failed field...
> 
> > +	),
> > +
> > +	TP_fast_assign(
> > +		__entry->addr = addr;
> > +		__entry->size = size;
> > +		__entry->align = align;
> > +		__entry->vstart = vstart;
> > +		__entry->vend = vend;
> 
> And instead have:
> 
> 		__entry->failed = addr == vend;
> 
> Why pass in a parameter that can be calculated in the trace event logic?
>
It can be. A condition about when it is failed or not is taken on upper
level because it might be changed afterwards. So a trace event is not
aware about it thus no need in adaptation.

But i do not have a strong opinion here. I can prepare a patch to
eliminate it.

What is your preference?

--
Uladzislau Rezki


  reply	other threads:[~2022-11-14 16:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 18:10 [PATCH v2 0/7] Add basic trace events for vmap/vmalloc (v2) Uladzislau Rezki (Sony)
2022-10-18 18:10 ` [PATCH v2 1/7] mm: vmalloc: Add alloc_vmap_area trace event Uladzislau Rezki (Sony)
2022-10-20 11:22   ` Christoph Hellwig
2022-11-14 15:53   ` Steven Rostedt
2022-11-14 16:55     ` Uladzislau Rezki [this message]
2022-10-18 18:10 ` [PATCH v2 2/7] mm: vmalloc: Add purge_vmap_area_lazy " Uladzislau Rezki (Sony)
2022-10-20 11:22   ` Christoph Hellwig
2022-10-18 18:10 ` [PATCH v2 3/7] mm: vmalloc: Add free_vmap_area_noflush " Uladzislau Rezki (Sony)
2022-10-20 11:22   ` Christoph Hellwig
2022-10-18 18:10 ` [PATCH v2 4/7] mm: vmalloc: Use trace_alloc_vmap_area event Uladzislau Rezki (Sony)
2022-10-20 11:23   ` Christoph Hellwig
2022-10-18 18:10 ` [PATCH v2 5/7] mm: vmalloc: Use trace_purge_vmap_area_lazy event Uladzislau Rezki (Sony)
2022-10-20 11:25   ` Christoph Hellwig
2022-10-20 12:55     ` Uladzislau Rezki
2022-10-23 22:51   ` kernel test robot
2022-10-24 12:48     ` Uladzislau Rezki
2022-10-18 18:10 ` [PATCH v2 6/7] mm: vmalloc: Use trace_free_vmap_area_noflush event Uladzislau Rezki (Sony)
2022-10-20 11:25   ` Christoph Hellwig
2022-10-18 18:10 ` [PATCH v2 7/7] vmalloc: Add reviewers for vmalloc code Uladzislau Rezki (Sony)
2022-10-20 11:25   ` Christoph Hellwig
2022-10-18 18:23 ` [PATCH v2 0/7] Add basic trace events for vmap/vmalloc (v2) Steven Rostedt
2022-10-18 18:25   ` Steven Rostedt
2022-10-19 11:49     ` Uladzislau Rezki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3Jy6rSAiHco5q7v@pc636 \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@gmail.com \
    --cc=oleksiy.avramchenko@sony.com \
    --cc=rostedt@goodmis.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.