lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140319104515.GA7423@krava.brq.redhat.com>
Date:	Wed, 19 Mar 2014 11:45:15 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Don Zickus <dzickus@...hat.com>
Cc:	acme@...stprotocols.net, LKML <linux-kernel@...r.kernel.org>,
	jmario@...hat.com, fowles@...each.com, eranian@...gle.com
Subject: Re: [PATCH 02/19] perf, sort:  Add physid sorting based on mmap2 data

On Fri, Feb 28, 2014 at 12:42:51PM -0500, Don Zickus wrote:

SNIP

> +static int64_t
> +sort__physid_cmp(struct hist_entry *left, struct hist_entry *right)
> +{
> +        u64 l, r;
> +        struct map *l_map = left->mem_info->daddr.map;
> +        struct map *r_map = right->mem_info->daddr.map;
> +
> +	/* store all NULL mem maps at the bottom */
> +	/* shouldn't even need this check, should have stubs */
> +	if (!left->mem_info->daddr.map || !right->mem_info->daddr.map)
> +		return 1;
> +
> +        /* 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->mem_info->daddr.al_addr;
> +        r = right->mem_info->daddr.al_addr;
> +
> +        if (l_map->maj || l_map->min || l_map->ino || l_map-> ino_generation) {
> +                /* 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 = TRUE;
> +
> +                if (l > r) return -1;
> +                if (l < r) return 1;
> +
> +                /* sorting by iaddr makes calculations easier later */
> +                if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> +                if (left->mem_info->iaddr.al_addr < right->mem_info->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 = TRUE;
> +
> +                if (l > r) return -1;
> +                if (l < r) return 1;
> +
> +                /* sorting by iaddr makes calculations easier later */
> +                if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> +                if (left->mem_info->iaddr.al_addr < right->mem_info->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 = TRUE;
> +
> +                if (l > r) return -1;
> +                if (l < r) return 1;
> +
> +                /* sorting by iaddr makes calculations easier later */
> +                if (left->mem_info->iaddr.al_addr > right->mem_info->iaddr.al_addr) return -1;
> +                if (left->mem_info->iaddr.al_addr < right->mem_info->iaddr.al_addr) return 1;
> +        }

do you need single column for 'physid' ?

my first idea was to have separate sort entries for all checked entries:
(same way like for memory memory_sort_dimensions)

  - mem_info->daddr.al_addr (we already have 'addr' check)
  - mem_info->iaddr.al_addr
  - thread->pid_ (we have only 'tid' check so far)
  - l_map->maj, l_map->min, l_map->ino, l_map, ino_generation (we could probably group these)

and init sort order with:

   sort_order = "physid,pid,...";

'...' is whatever name you choose for above entries


you can check the sort entries cmp function call
logic in hist_entry__cmp function

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ