public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Michael Petlan <mpetlan@redhat.com>,
	Andi Kleen <ak@linux.intel.com>,
	Stephane Eranian <eranian@google.com>,
	Jin Yao <yao.jin@linux.intel.com>,
	Alexey Budankov <alexey.budankov@linux.intel.com>
Subject: Re: [PATCHv2 0/2] perf tools: Share struct map after clone
Date: Tue, 19 Nov 2019 12:06:41 +0100	[thread overview]
Message-ID: <20191119110641.GC21165@krava> (raw)
In-Reply-To: <20191118214851.GA17315@kernel.org>

On Mon, Nov 18, 2019 at 06:48:51PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 18, 2019 at 01:14:00PM +0100, Jiri Olsa escreveu:
> > On Tue, Oct 29, 2019 at 09:58:55PM +0100, Jiri Olsa wrote:
> > > > > 
> > > > > Also available in here:
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> > > > >   perf/map_shared
> 
> > > > I rebased to latest perf/core and pushed the branch out
> 
> > > rebased and pushed out
>  
> > heya,
> > I lost track of this.. what's the status, are you going with your
> > version, or is this one still in? I don't see any of them in latest
> > code..
> 
> So, I'm still working on and off on this, current status is at:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/map_share
> 
> Its just one patch more than perf/core, the one that does the sharing.
> 
> The thing is, as I'm going over all the fields in 'struct map', it seems
> that we'll end up with just one cacheline per instance, as there are
> things there that are not strictly related to a map, but to a map_group
> (unmap_ip/map_ip), or to a dso (maj, min, ino, ino_generation), and some
> need less than what is allocated to them.
> 
> Current status is:
> 
> [root@quaco ~]# pahole -C map ~acme/bin/perf
> struct map {
> 	union {
> 		struct rb_node rb_node __attribute__((__aligned__(8))); /*     0    24 */
> 		struct list_head node;                   /*     0    16 */
> 	} __attribute__((__aligned__(8)));                                               /*     0    24 */
> 	u64                        start;                /*    24     8 */
> 	u64                        end;                  /*    32     8 */
> 	_Bool                      erange_warned:1;      /*    40: 0  1 */
> 	_Bool                      priv:1;               /*    40: 1  1 */
> 
> 	/* XXX 6 bits hole, try to pack */
> 	/* XXX 3 bytes hole, try to pack */
> 
> 	u32                        prot;                 /*    44     4 */
> 	u64                        pgoff;                /*    48     8 */
> 	u64                        reloc;                /*    56     8 */
> 	/* --- cacheline 1 boundary (64 bytes) --- */
> 	u64                        (*map_ip)(struct map *, u64); /*    64     8 */
> 	u64                        (*unmap_ip)(struct map *, u64); /*    72     8 */
> 	struct dso *               dso;                  /*    80     8 */
> 	refcount_t                 refcnt;               /*    88     4 */
> 	u32                        flags;                /*    92     4 */
> 
> 	/* size: 96, cachelines: 2, members: 13 */
> 	/* sum members: 92, holes: 1, sum holes: 3 */
> 	/* sum bitfield members: 2 bits, bit holes: 1, sum bit holes: 6 bits */
> 	/* forced alignments: 1 */
> 	/* last cacheline: 32 bytes */
> } __attribute__((__aligned__(8)));
> [root@quaco ~]#
> 
> This is with the tentative move of maj/min/ino/ino_generation to 'struct
> dso', but that needs more work to match the sort order that touches it
> "dcacheline", i.e. a map that comes with the same backing DSO but
> different values for those fields is not the same DSO, right?
> 
> Right now with moving the maj/min/etc to dso, in the map_share patch we
> get the structure used to keep shared entries in the rb_tree at 40
> bytes, under one cacheline, while the full 'struct map' is 32 bytes more
> than one cacheline, so still good for sharing:
> 
> [acme@quaco perf]$ pahole -C map_node ~/bin/perf
> struct map_node {
> 	union {
> 		struct rb_node rb_node __attribute__((__aligned__(8))); /*     0    24 */
> 		struct list_head node;                   /*     0    16 */
> 	} __attribute__((__aligned__(8)));               /*     0    24 */
> 	refcount_t                 refcnt;               /*    24     4 */
> 	_Bool                      is_node:1;            /*    28: 0  1 */
> 
> 	/* XXX 7 bits hole, try to pack */
> 	/* XXX 3 bytes hole, try to pack */
> 
> 	struct map *               map;                  /*    32     8 */
> 
> 	/* size: 40, cachelines: 1, members: 4 */
> 	/* sum members: 36, holes: 1, sum holes: 3 */
> 	/* sum bitfield members: 1 bits, bit holes: 1, sum bit holes: 7 bits */
> 	/* forced alignments: 1 */
> 	/* last cacheline: 40 bytes */
> } __attribute__((__aligned__(8)));
> [acme@quaco perf]$ pahole -C map ~/bin/perf
> struct map {
> 	union {
> 		struct rb_node rb_node __attribute__((__aligned__(8))); /*     0    24 */
> 		struct list_head node;                   /*     0    16 */
> 	} __attribute__((__aligned__(8)));               /*     0    24 */
> 	refcount_t                 refcnt;               /*    24     4 */
> 	_Bool                      is_node:1;            /*    28: 0  1 */
> 	_Bool                      erange_warned:1;      /*    28: 1  1 */
> 	_Bool                      priv:1;               /*    28: 2  1 */
> 
> 	/* XXX 5 bits hole, try to pack */
> 	/* XXX 3 bytes hole, try to pack */
> 
> 	u64                        start;                /*    32     8 */
> 	u64                        end;                  /*    40     8 */
> 	u64                        pgoff;                /*    48     8 */
> 	u64                        reloc;                /*    56     8 */
> 	/* --- cacheline 1 boundary (64 bytes) --- */
> 	u64                        (*map_ip)(struct map *, u64); /*    64     8 */
> 	u64                        (*unmap_ip)(struct map *, u64); /*    72     8 */
> 	struct dso *               dso;                  /*    80     8 */
> 	u32                        flags;                /*    88     4 */
> 	u32                        prot;                 /*    92     4 */
> 
> 	/* size: 96, cachelines: 2, members: 14 */
> 	/* sum members: 92, holes: 1, sum holes: 3 */
> 	/* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 5 bits */
> 	/* forced alignments: 1 */
> 	/* last cacheline: 32 bytes */
> } __attribute__((__aligned__(8)));
> [acme@quaco perf]$
> 
> So give me some more time, please :-)

sure ;-) I just did not want to loose track of this

thanks,
jirka


      reply	other threads:[~2019-11-19 11:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16  8:22 [PATCHv2 0/2] perf tools: Share struct map after clone Jiri Olsa
2019-10-16  8:22 ` [PATCH 1/2] perf tools: Separate shareable part of 'struct map' into 'struct map_shared' Jiri Olsa
2019-10-16  8:22 ` [PATCH 2/2] perf tools: Make 'struct map_shared' truly shared Jiri Olsa
2019-10-23  7:55 ` [PATCHv2 0/2] perf tools: Share struct map after clone Jiri Olsa
2019-10-29 20:58   ` Jiri Olsa
2019-11-18 12:14     ` Jiri Olsa
2019-11-18 21:48       ` Arnaldo Carvalho de Melo
2019-11-19 11:06         ` Jiri Olsa [this message]

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=20191119110641.GC21165@krava \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=yao.jin@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox