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

[Jiri Olsa]

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?

jirka
--
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/