All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@ghostprotocols.net, peterz@infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	namhyung@gmail.com, eranian@google.com,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH 6/7] perf: Add support to dynamically get cacheline size
Date: Fri, 23 May 2014 13:30:26 -0400	[thread overview]
Message-ID: <20140523173026.GQ50500@redhat.com> (raw)
In-Reply-To: <20140523170901.GF1074@krava>

On Fri, May 23, 2014 at 07:09:01PM +0200, Jiri Olsa wrote:
> On Mon, May 19, 2014 at 03:13:52PM -0400, Don Zickus wrote:
> 
> SNIP
> 
> > diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
> > index 61a6548..b3e7b22 100644
> > --- a/tools/perf/util/cpumap.h
> > +++ b/tools/perf/util/cpumap.h
> > @@ -81,4 +81,16 @@ static inline int cpu__get_node(int cpu)
> >  	return cpunode_map[cpu];
> >  }
> >  
> > +int cacheline_size;
> 
> hum, so cacheline_size does not need to be global, if you use
> cpu__cacheline_size in your next patch, right?

I made cpu__cacheline_size an inline so I think it does.  If I stick that
function in cpumap.c then yeah I would agree it would not need to be
global.

Being that is was going to be called repeatedly while processing each
event I opted to make it an inline.  I guess I could change that if it
matters.

> 
> > +
> > +int cpu__setup_cacheline_size(void);
> > +
> > +static inline int cpu__cacheline_size(void)
> > +{
> > +	if (unlikely(!cacheline_size))
> > +		pr_debug("cacheline size not initialized\n");
> > +
> > +	return cacheline_size;
> > +}
> > +
> >  #endif /* __PERF_CPUMAP_H */
> > diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> > index 635cd8f..50adbfb 100644
> > --- a/tools/perf/util/sort.c
> > +++ b/tools/perf/util/sort.c
> > @@ -2,6 +2,7 @@
> >  #include "hist.h"
> >  #include "comm.h"
> >  #include "symbol.h"
> > +#include "cpumap.h"
> >  
> >  regex_t		parent_regex;
> >  const char	default_parent_pattern[] = "^sys_|^do_page_fault";
> > @@ -1117,6 +1118,8 @@ int setup_sorting(void)
> >  		return -ENOMEM;
> >  	}
> >  
> > +	cpu__setup_cacheline_size();
> > +
> 
> I dont think this is the best place to call the setup,
> on the other hand I can't think of any suitable ;-)
> 
> how about lazy initialization from cpu__cacheline_size?
> 
> We also have page_size variable which gets initialized
> in main and is globaly accesable. I wonder we should
> add the cacheline_size variable in the same way.

That seems to make sense.  I can stick the variable in util.c|h then?

Cheers,
Don

  reply	other threads:[~2014-05-23 17:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 19:13 [PATCH 0/7 V3] x86, nmi: Various fixes and cleanups Don Zickus
2014-05-19 19:13 ` [PATCH 1/7] events, perf: Pass protection and flags bits through mmap2 interface Don Zickus
2014-06-12 12:02   ` [tip:perf/core] " tip-bot for Peter Zijlstra
2014-05-19 19:13 ` [PATCH 2/7] Revert "perf: Disable PERF_RECORD_MMAP2 support" Don Zickus
2014-05-19 19:13 ` [PATCH 3/7] perf: Update mmap2 interface with protection and flag bits Don Zickus
2014-06-12 12:02   ` [tip:perf/core] perf tools: " tip-bot for Don Zickus
2014-05-19 19:13 ` [PATCH 4/7] perf report: Add mem-mode documentation to report command Don Zickus
2014-06-12 12:02   ` [tip:perf/core] " tip-bot for Don Zickus
2014-05-19 19:13 ` [PATCH 5/7] perf: Add cpumode to struct hist_entry Don Zickus
2014-05-19 19:13 ` [PATCH 6/7] perf: Add support to dynamically get cacheline size Don Zickus
2014-05-23 16:54   ` Jiri Olsa
2014-05-23 17:18     ` Don Zickus
2014-05-23 17:09   ` Jiri Olsa
2014-05-23 17:30     ` Don Zickus [this message]
2014-05-19 19:13 ` [PATCH 7/7] perf: Add dcacheline sort Don Zickus
2014-05-23 17:14   ` Jiri Olsa
  -- strict thread matches above, loose matches on Subject: below --
2014-05-27 16:28 [PATCH 0/7 V4] perf: Enable mmap2 and add dcacheline sorting Don Zickus
2014-05-27 16:28 ` [PATCH 6/7] perf: Add support to dynamically get cacheline size Don Zickus
2014-05-30  7:09   ` Namhyung Kim

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=20140523173026.GQ50500@redhat.com \
    --to=dzickus@redhat.com \
    --cc=acme@ghostprotocols.net \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@gmail.com \
    --cc=peterz@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.