Message-ID: <551C983A.3030300@huawei.com>
Date: Thu, 2 Apr 2015 09:15:38 +0800
From: Wang Nan <wangnan0@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Jiri Olsa <jolsa@redhat.com>
CC: <acme@kernel.org>, <jolsa@kernel.org>, <namhyung@kernel.org>,
        <mingo@redhat.com>, <lizefan@huawei.com>, <pi3orama@163.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] perf tools: report: introduce --map-adjustment argument.
References: <1427884395-241111-1-git-send-email-wangnan0@huawei.com> <1427884395-241111-4-git-send-email-wangnan0@huawei.com> <20150401132140.GC10820@krava.brq.redhat.com>
In-Reply-To: <20150401132140.GC10820@krava.brq.redhat.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2578
Lines: 72

On 2015/4/1 21:21, Jiri Olsa wrote:
> On Wed, Apr 01, 2015 at 10:33:14AM +0000, Wang Nan wrote:
>> This patch introduces a --map-adjustment argument for perf report. The
>> goal of this option is to deal with private dynamic loader used in some
>> special program.
>>
> 
> SNIP
> 
>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>> index 051883a..dc9e91e 100644
>> --- a/tools/perf/util/machine.c
>> +++ b/tools/perf/util/machine.c
>> @@ -1155,21 +1155,291 @@ out_problem:
>>  	return -1;
>>  }
>>  
>> +/*
>> + * Users are allowed to provide map adjustment setting for the case
>> + * that an address range is actually privatly mapped but known to be
>> + * ELF object file backended. Like this:
>> + *
>> + * |<- copied from libx.so ->|  |<- copied from liby.so ->|
>> + * |<-------------------- MMAP area --------------------->|
>> + *
>> + * When dealing with such mmap events, try to obey user adjustment.
>> + * Such adjustment settings are not allowed overlapping.
>> + * Adjustments won't be considered as valid code until real MMAP events
>> + * take place. Therefore, users are allowed to provide adjustments which
>> + * cover never mapped areas, like:
>> + *
>> + * |<- libx.so ->|  |<- liby.so ->|
>> + *      |<-- MMAP area -->|
>> + *
>> + * This feature is useful when dealing with private dynamic linkers,
>> + * which assemble code piece from different ELF objects.
>> + *
>> + * map_adj_list is an ordered linked list. Order of two adjustments is
>> + * first defined by their pid, and then by their start address.
>> + * Therefore, adjustments for specific pids are groupped together
>> + * naturally.
>> + */
>> +static LIST_HEAD(map_adj_list);
> 
> we dont like global stuff ;-)
> 
> I think this belongs to the machine object, which is created
> within the perf_session__new, so after options parsing.. hum
> 

Do you think such struct map_adj objects should better reside in thread
objects?

SNIP

> 
> just curious.. how many --map-adjust entries do you normaly use?
> maybe if it's bigger number then a) using rb_tree might be faster
> and b) using some sort of config file could be better way for
> input might be easier
> 

The address and pid are dynamically allocated so I don't think static config
file is a good way for input. I'll consider rb_tree in my next post.

Thank you.

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