linux-kernel - Re: [PATCH v2 10/15] perf record: manage thread specific data array

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: <2a32cb3c-fc22-10cc-8ae2-b62781f48194@gmail.com>
Date:   Mon, 26 Oct 2020 11:39:05 +0300
From:   Alexei Budankov <budankov.lore@...il.com>
To:     Jiri Olsa <jolsa@...hat.com>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 10/15] perf record: manage thread specific data array


On 24.10.2020 18:44, Jiri Olsa wrote:
> On Wed, Oct 21, 2020 at 07:04:26PM +0300, Alexey Budankov wrote:
>>
>> Provide allocation, initialization, finalization and releasing of
>> thread specific objects at thread specific data array. Allocate
>> thread specific object for every data buffer making one-to-one
>> relation between data buffer and a thread processing the buffer.
>> Deliver event fd related signals to thread's pollfd object.
>> Deliver thread control commands to ctlfd_pos fd of thread 1+.
>> Deliver tool external control commands via ctlfd_pos fd of thread 0.
>>
>> Signed-off-by: Alexey Budankov <alexey.budankov@...ux.intel.com>
>> ---
>>  tools/perf/builtin-record.c | 101 ++++++++++++++++++++++++++++++++++--
>>  1 file changed, 98 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 8e512096a060..89cb8e913fb3 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -884,6 +884,94 @@ static int record__kcore_copy(struct machine *machine, struct perf_data *data)
>>  	return kcore_copy(from_dir, kcore_dir);
>>  }
>>  
>> +static int record__alloc_thread_data(struct record *rec, struct mmap *mmaps, int nr_mmaps,
>> +				     struct fdarray *evlist_pollfd, int ctlfd_pos)
>> +{
>> +	int i, j, k, nr_thread_data;
>> +	struct thread_data *thread_data;
>> +
>> +	rec->nr_thread_data = nr_thread_data = nr_mmaps;
>> +	rec->thread_data = thread_data = zalloc(rec->nr_thread_data * sizeof(*(rec->thread_data)));
>> +	if (!thread_data) {
>> +		pr_err("Failed to allocate thread data\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	for (i = 0; i < nr_thread_data; i++) {
>> +		short revents;
>> +		int pos, fd;
>> +
>> +		thread_data[i].tid = -1;
>> +
>> +		if (pipe(thread_data[i].comm.msg) ||
>> +		    pipe(thread_data[i].comm.ack)) {
>> +			pr_err("Failed to create thread comm pipes, errno %d\n", errno);
>> +			return -ENOMEM;
>> +		}
> 
> the original code was using state flag and pthread_cond,
> which I think is more readable
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/commit/?h=perf/record_threads&id=a7da527ff8be69572c6d17525c03c6fe394503c8
> https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/commit/?h=perf/record_threads&id=eb85ce4da64a885fdb6c77cfc5bd71312fe02e2a

Yes, right, but messaging scales better and that critical section
to just increment global counter in memory looked as over complication.

> 
>> +
>> +		thread_data[i].maps = &mmaps[i];
>> +		thread_data[i].nr_mmaps = 1;
>> +
>> +		thread_data[i].rec = rec;
>> +
>> +		fdarray__init(&(thread_data[i].pollfd), 64);
>> +
>> +		for (j = 0; j < thread_data[i].nr_mmaps; j++) {
>> +			struct mmap *map = &(thread_data[i].maps[j]);
>> +
>> +			for (k = 0; k < evlist_pollfd->nr; k++) {
>> +				if (evlist_pollfd->priv[k].ptr != map)
>> +					continue;
>> +
>> +				fd = evlist_pollfd->entries[k].fd;
>> +				revents = evlist_pollfd->entries[k].events;
>> +				pos = fdarray__add(&(thread_data[i].pollfd),
>> +						fd, revents | POLLERR | POLLHUP,
>> +						fdarray_flag__default);
>> +				if (pos >= 0)
>> +					thread_data[i].pollfd.priv[pos].ptr = map;
>> +				else
>> +					return -ENOMEM;
> 
> I added function for that:
>   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/commit/?h=perf/record_threads&id=8aa6e68a7471b9d25af1a9eebfa9321433366a17

Ok, but it is not clone operation it is more like ordinary adding of
fd into another pollfd object. It could be wrapped into a function
e.g. fdarray__dup(pollfd_dst, fd_src, fd_revents)

Alexei