Re: [PATCH 09/21] perf, c2c: Add rbtree sorted on mmap2 data

From: Don Zickus
Date: Thu Feb 20 2014 - 21:46:37 EST


On Tue, Feb 18, 2014 at 02:04:05PM +0100, Jiri Olsa wrote:
> On Mon, Feb 10, 2014 at 12:29:04PM -0500, Don Zickus wrote:
> > In order for the c2c tool to work correctly, it needs to properly
> > sort all the records on uniquely identifiable data addresses. These
> > unique addresses are converted from virtual addresses provided by the
> > hardware into a kernel address using an mmap2 record as the decoder.
> >
>
> SNIP
>
> > +static int physid_cmp(struct c2c_entry *left, struct c2c_entry *right)
> > +{
> > + u64 l, r;
> > + struct map *l_map = left->mi->daddr.map;
> > + struct map *r_map = right->mi->daddr.map;
> > +
> > + /* group event types together */
> > + if (left->cpumode > right->cpumode) return 1;
> > + if (left->cpumode < right->cpumode) return -1;
> > +
> > + if (l_map->maj > r_map->maj) return 1;
> > + if (l_map->maj < r_map->maj) return -1;
> > +
> > + if (l_map->min > r_map->min) return 1;
> > + if (l_map->min < r_map->min) return -1;
> > +
> > + if (l_map->ino > r_map->ino) return 1;
> > + if (l_map->ino < r_map->ino) return -1;
> > +
> > + if (l_map->ino_generation > r_map->ino_generation) return 1;
> > + if (l_map->ino_generation < r_map->ino_generation) return -1;
> > +
> > + /*
> > + * Addresses with no major/minor numbers are assumed to be
> > + * anonymous in userspace. Sort those on pid then address.
> > + *
> > + * The kernel and non-zero major/minor mapped areas are
> > + * assumed to be unity mapped. Sort those on address then pid.
> > + */
> > +
> > + /* al_addr does all the right addr - start + offset calculations */
> > + l = left->mi->daddr.al_addr;
> > + r = right->mi->daddr.al_addr;
> > +
> > + if (l_map->maj || l_map->min) {
> > + /* mmapped areas */
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* entries with same maj/min/ino/inogen are in same address space */
> > + right->color = REGION_SAME;
> > +
> > + if (l > r) return 1;
> > + if (l < r) return -1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mi->iaddr.al_addr > right->mi->iaddr.al_addr) return 1;
> > + if (left->mi->iaddr.al_addr < right->mi->iaddr.al_addr) return -1;
> > +
> > + if (left->thread->pid_ > right->thread->pid_) return 1;
> > + if (left->thread->pid_ < right->thread->pid_) return -1;
> > +
> > + if (left->thread->tid > right->thread->tid) return 1;
> > + if (left->thread->tid < right->thread->tid) return -1;
> > + } else if (left->cpumode == PERF_RECORD_MISC_KERNEL) {
> > + /* kernel mapped areas where 'start' doesn't matter */
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* whole kernel region is in the same address space */
> > + right->color = REGION_SAME;
> > +
> > + if (l > r) return 1;
> > + if (l < r) return -1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mi->iaddr.al_addr > right->mi->iaddr.al_addr) return 1;
> > + if (left->mi->iaddr.al_addr < right->mi->iaddr.al_addr) return -1;
> > +
> > + if (left->thread->pid_ > right->thread->pid_) return 1;
> > + if (left->thread->pid_ < right->thread->pid_) return -1;
> > +
> > + if (left->thread->tid > right->thread->tid) return 1;
> > + if (left->thread->tid < right->thread->tid) return -1;
> > + } else {
> > + /* userspace anonymous */
> > + if (left->thread->pid_ > right->thread->pid_) return 1;
> > + if (left->thread->pid_ < right->thread->pid_) return -1;
> > +
> > + if (left->thread->tid > right->thread->tid) return 1;
> > + if (left->thread->tid < right->thread->tid) return -1;
> > +
> > + /* hack to mark similar regions, 'right' is new entry */
> > + /* userspace anonymous address space is contained within pid */
> > + right->color = REGION_SAME;
> > +
> > + if (l > r) return 1;
> > + if (l < r) return -1;
> > +
> > + /* sorting by iaddr makes calculations easier later */
> > + if (left->mi->iaddr.al_addr > right->mi->iaddr.al_addr) return 1;
> > + if (left->mi->iaddr.al_addr < right->mi->iaddr.al_addr) return -1;
> > + }
> > +
> > + return 0;
> > +}
>
> there's sort object doing exatly this over hist_entry's
>
> Is there any reason not to use hist_entries?

So looking over hist_entry, I realize, what do I gain? I implemented it
and realized I had to add, 'cpumode', 'tid' and a 'private' field to
struct hist_entry. Then because I have my own report implementation, I
still have to copy and paste a ton of stuff from builtin-report over to
here (including callchain support).

Not unless you are expecting me to add giant chunks of code to
builtin-report.c?

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/