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
prev parent 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 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.