From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team@lge.com
Subject: Re: [PATCH v9 2/3]: perf record: enable asynchronous trace writing
Date: Fri, 5 Oct 2018 11:31:11 +0300 [thread overview]
Message-ID: <dc944fcf-cbb6-9b88-bc1c-606eb027a6ac@linux.intel.com> (raw)
In-Reply-To: <20181005071615.GC3768@sejong>
Hi,
On 05.10.2018 10:16, Namhyung Kim wrote:
> On Wed, Oct 03, 2018 at 07:12:10PM +0300, Alexey Budankov wrote:
<SNIP>
>> +static void record__aio_sync(struct perf_mmap *md)
>> +{
>> + struct aiocb *cblock = &md->cblock;
>> + struct timespec timeout = { 0, 1000 * 1000 * 1 }; // 1ms
>> +
>> + do {
>> + if (cblock->aio_fildes == -1 || record__aio_complete(md, cblock))
>> + return;
>> +
>> + while (aio_suspend((const struct aiocb**)&cblock, 1, &timeout)) {
>> + if (!(errno == EAGAIN || errno == EINTR))
>> + pr_err("failed to sync perf data, error: %m\n");
>
> Is there somthing we can do in this error case? Any chance it gets
> stuck in the loop?
Not really. Currently, in glibc, it can block on a mutex only.
>
>
>> + }
>> + } while (1);
>> +}
>> +
>> +static int record__aio_pushfn(void *to, struct aiocb *cblock, void *bf, size_t size)
>> +{
>> + off_t off;
>> + struct record *rec = to;
>> + int ret, trace_fd = rec->session->data->file.fd;
>> +
>> + rec->samples++;
>> +
>> + off = lseek(trace_fd, 0, SEEK_CUR);
>> + lseek(trace_fd, off + size, SEEK_SET);
>
> It'd be nice if these lseek() could be removed and use
> rec->bytes_written instead.
Well, this could be implemented like this avoiding lseek() in else branch:
off = lseek(trace_fd, 0, SEEK_CUR);
ret = record__aio_write(cblock, trace_fd, bf, size, off);
if (!ret) {
lseek(trace_fd, off + size, SEEK_SET);
rec->bytes_written += size;
if (switch_output_size(rec))
trigger_hit(&switch_output_trigger);
}
>
>
>> + ret = record__aio_write(cblock, trace_fd, bf, size, off);
>> + if (!ret) {
>> + rec->bytes_written += size;
>> +
>> + if (switch_output_size(rec))
>> + trigger_hit(&switch_output_trigger);
>
> Doesn't it need the _sync() before the trigger? Maybe it should be
> moved to record__mmap_read_evlist() or so..
Currently trigger just updates variable state.
The state is then checked thru separate API at __cmd_record() where
record__mmap_read_sync() is called prior switching to a new trace file
or finishing collection.
>>
<SNIP>
>> if (map->base) {
>> +#ifndef HAVE_AIO_SUPPORT
>> if (perf_mmap__push(map, rec, record__pushfn) != 0) {
>> rc = -1;
>> goto out;
>> }
>> +#else
>> + if (!rec->opts.nr_cblocks) {
>> + if (perf_mmap__push(map, rec, record__pushfn) != 0) {
>> + rc = -1;
>> + goto out;
>> + }
>> + } else {
>> + /*
>> + * Call record__aio_sync() to wait till map->data buffer
>> + * becomes available after previous aio write request.
>> + */
>> + record__aio_sync(map);
>> + if (perf_mmap__aio_push(map, rec, record__aio_pushfn) != 0) {
>> + rc = -1;
>> + goto out;
>> + }
>> + }
>> +#endif
>
> If dummy aio functions are provided, the #ifdef can be removed and
> just use the #else part assuming opts.nr_cblocks == 0.
Yes, it looks a little bit cumbersome. Would this be more compact?
if (map->base) {
#ifdef HAVE_AIO_SUPPORT
if (!rec->opts.nr_cblocks) {
#endif
if (perf_mmap__push(map, rec, record__pushfn) != 0) {
rc = -1;
goto out;
}
#ifdef HAVE_AIO_SUPPORT
} else {
int idx;
/*
* Call record__aio_sync() to wait till map->data buffer
* becomes available after previous aio write request.
*/
idx = record__aio_sync(map, false);
if (perf_mmap__aio_push(map, rec, idx, record__aio_pushfn) != 0) {
rc = -1;
goto out;
}
}
#endif
}
Thanks,
Alexey
next prev parent reply other threads:[~2018-10-05 8:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 15:54 [PATCH v9 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads Alexey Budankov
2018-10-03 16:01 ` [PATCH v9 1/3]: perf util: map data buffer for preserving collected data Alexey Budankov
2018-10-05 6:23 ` Namhyung Kim
2018-10-05 7:03 ` Alexey Budankov
2018-10-05 7:29 ` Alexey Budankov
2018-10-03 16:12 ` [PATCH v9 2/3]: perf record: enable asynchronous trace writing Alexey Budankov
2018-10-05 7:16 ` Namhyung Kim
2018-10-05 8:31 ` Alexey Budankov [this message]
2018-10-05 8:48 ` Namhyung Kim
2018-10-05 9:39 ` Alexey Budankov
2018-10-05 10:55 ` Namhyung Kim
2018-10-05 11:50 ` Alexey Budankov
2018-10-05 15:53 ` Alexey Budankov
2018-10-03 16:17 ` [PATCH v9 3/3]: perf record: extend trace writing to multi AIO Alexey Budankov
2018-10-05 7:22 ` Namhyung Kim
2018-10-05 7:54 ` Alexey Budankov
-- strict thread matches above, loose matches on Subject: below --
2018-10-05 13:35 [PATCH v10 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads Alexey Budankov
2018-10-05 13:49 ` [PATCH v9 2/3]: perf record: enable asynchronous trace writing 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=dc944fcf-cbb6-9b88-bc1c-606eb027a6ac@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=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.