From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] perf record: bind the AIO user space buffers to nodes
Date: Wed, 9 Jan 2019 12:12:37 +0300 [thread overview]
Message-ID: <d03c0f6b-57d8-773b-7d82-316c2bef2fb3@linux.intel.com> (raw)
In-Reply-To: <20190101214117.GI13760@krava>
Hi,
On 02.01.2019 0:41, Jiri Olsa wrote:
> On Mon, Dec 24, 2018 at 03:24:36PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>> +static void perf_mmap__aio_free(void **data, size_t len __maybe_unused)
>> +{
>> + zfree(data);
>> +}
>> +
>> +static void perf_mmap__aio_bind(void *data __maybe_unused, size_t len __maybe_unused,
>> + int cpu __maybe_unused, int affinity __maybe_unused)
>> +{
>> +}
>> +#endif
>> +
>> static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
>> {
>> int delta_max, i, prio;
>> @@ -177,11 +220,13 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
>> }
>> delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
>> for (i = 0; i < map->aio.nr_cblocks; ++i) {
>> - map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
>> + size_t mmap_len = perf_mmap__mmap_len(map);
>> + perf_mmap__aio_alloc(&(map->aio.data[i]), mmap_len);
>> if (!map->aio.data[i]) {
>> pr_debug2("failed to allocate data buffer area, error %m");
>> return -1;
>> }
>> + perf_mmap__aio_bind(map->aio.data[i], mmap_len, map->cpu, mp->affinity);
>
> this all does not work if bind fails.. I think we need to
> propagate the error value here and fail
Proceeding further from this point still makes sense because
the buffer is available for operations and thread migration
alone can bring performance benefits. So the error is not fatal
and an explicit warning is implemented in v3. If you still think
it is better to propagate error from here it can be implemented.
Thanks,
Alexey
>
> jirka
>
next prev parent reply other threads:[~2019-01-09 9:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-24 12:11 [PATCH v2 0/4] Reduce NUMA related overhead in perf record profiling on large server systems Alexey Budankov
2018-12-24 12:23 ` [PATCH v2 1/4] perf record: allocate affinity masks Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:10 ` Alexey Budankov
2018-12-24 12:24 ` [PATCH v2 2/4] perf record: bind the AIO user space buffers to nodes Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:10 ` Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:10 ` Alexey Budankov
2019-01-01 21:41 ` Jiri Olsa
2019-01-09 9:12 ` Alexey Budankov [this message]
2019-01-09 16:49 ` Jiri Olsa
2019-01-09 18:14 ` Alexey Budankov
2018-12-24 12:27 ` [PATCH v2 3/4] perf record: apply affinity masks when reading mmap buffers Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:13 ` Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:14 ` Alexey Budankov
2018-12-24 12:28 ` [PATCH v2 4/4] perf record: implement --affinity=node|cpu option Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:15 ` Alexey Budankov
2019-01-01 21:39 ` Jiri Olsa
2019-01-09 9:15 ` Alexey Budankov
2019-01-09 9:15 ` Alexey Budankov
-- strict thread matches above, loose matches on Subject: below --
2018-12-13 7:07 [PATCH v2 0/4] Reduce NUMA related overhead in perf record profiling on large server systems Alexey Budankov
2018-12-13 7:19 ` [PATCH v2 2/4] perf record: bind the AIO user space buffers to nodes Alexey Budankov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d03c0f6b-57d8-773b-7d82-316c2bef2fb3@linux.intel.com \
--to=alexey.budankov@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome