From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors
Date: Mon, 8 Jun 2020 12:54:31 +0300 [thread overview]
Message-ID: <2d80a43a-54cf-3d12-92fd-066217c95d76@linux.intel.com> (raw)
In-Reply-To: <20200608084344.GA1520715@krava>
On 08.06.2020 11:43, Jiri Olsa wrote:
> On Mon, Jun 08, 2020 at 11:08:56AM +0300, Alexey Budankov wrote:
>>
>> On 05.06.2020 19:15, Alexey Budankov wrote:
>>>
>>> On 05.06.2020 14:38, Jiri Olsa wrote:
>>>> On Fri, Jun 05, 2020 at 12:50:54PM +0200, Jiri Olsa wrote:
>>>>> On Wed, Jun 03, 2020 at 06:52:59PM +0300, Alexey Budankov wrote:
>>>>>>
>>>>>> Implement adding of file descriptors by fdarray__add_stat() to
>>>>>> fix-sized (currently 1) stat_entries array located at struct fdarray.
>>>>>> Append added file descriptors to the array used by poll() syscall
>>>>>> during fdarray__poll() call. Copy poll() result of the added
>>>>>> descriptors from the array back to the storage for analysis.
>>>>>>
>>>>>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>>>>>> ---
>>>>>> tools/lib/api/fd/array.c | 42 +++++++++++++++++++++++-
>>>>>> tools/lib/api/fd/array.h | 7 ++++
>>>>>> tools/lib/perf/evlist.c | 11 +++++++
>>>>>> tools/lib/perf/include/internal/evlist.h | 2 ++
>>>>>> 4 files changed, 61 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/tools/lib/api/fd/array.c b/tools/lib/api/fd/array.c
>>>>>> index 58d44d5eee31..b0027f2169c7 100644
>>>>>> --- a/tools/lib/api/fd/array.c
>>>>>> +++ b/tools/lib/api/fd/array.c
>>>>>> @@ -11,10 +11,16 @@
>>>>>>
>>>>>> void fdarray__init(struct fdarray *fda, int nr_autogrow)
>>>>>> {
>>>>>> + int i;
>>>>>> +
>>>>>> fda->entries = NULL;
>>>>>> fda->priv = NULL;
>>>>>> fda->nr = fda->nr_alloc = 0;
>>>>>> fda->nr_autogrow = nr_autogrow;
>>>>>> +
>>>>>> + fda->nr_stat = 0;
>>>>>> + for (i = 0; i < FDARRAY__STAT_ENTRIES_MAX; i++)
>>>>>> + fda->stat_entries[i].fd = -1;
>>>>>> }
>>>>>>
>>>>>> int fdarray__grow(struct fdarray *fda, int nr)
>>>>>> @@ -83,6 +89,20 @@ int fdarray__add(struct fdarray *fda, int fd, short revents)
>>>>>> return pos;
>>>>>> }
>>>>>>
>>>>>> +int fdarray__add_stat(struct fdarray *fda, int fd, short revents)
>>>>>> +{
>>>>>> + int pos = fda->nr_stat;
>>>>>> +
>>>>>> + if (pos >= FDARRAY__STAT_ENTRIES_MAX)
>>>>>> + return -1;
>>>>>> +
>>>>>> + fda->stat_entries[pos].fd = fd;
>>>>>> + fda->stat_entries[pos].events = revents;
>>>>>> + fda->nr_stat++;
>>>>>> +
>>>>>> + return pos;
>>>>>> +}
>>>>>> +
>>>>>> int fdarray__filter(struct fdarray *fda, short revents,
>>>>>> void (*entry_destructor)(struct fdarray *fda, int fd, void *arg),
>>>>>> void *arg)
>>>>>> @@ -113,7 +133,27 @@ int fdarray__filter(struct fdarray *fda, short revents,
>>>>>>
>>>>>> int fdarray__poll(struct fdarray *fda, int timeout)
>>>>>> {
>>>>>> - return poll(fda->entries, fda->nr, timeout);
>>>>>> + int nr, i, pos, res;
>>>>>> +
>>>>>> + nr = fda->nr;
>>>>>> +
>>>>>> + for (i = 0; i < fda->nr_stat; i++) {
>>>>>> + if (fda->stat_entries[i].fd != -1) {
>>>>>> + pos = fdarray__add(fda, fda->stat_entries[i].fd,
>>>>>> + fda->stat_entries[i].events);
>>>>>
>>>>> so every call to fdarray__poll will add whatever is
>>>>> in stat_entries to entries? how is it removed?
>>>>>
>>>>> I think you should either follow what Adrian said
>>>>> and put 'static' descriptors early and check for
>>>>> filter number to match it as an 'quick fix'
>>>>>
>>>>> or we should fix it for real and make it generic
>>>>>
>>>>> so currently the interface is like this:
>>>>>
>>>>> pos1 = fdarray__add(a, fd1 ... );
>>>>> pos2 = fdarray__add(a, fd2 ... );
>>>>> pos3 = fdarray__add(a, fd2 ... );
>>>>>
>>>>> fdarray__poll(a);
>>>>>
>>>>> num = fdarray__filter(a, revents, destructor, arg);
>>>>>
>>>>> when fdarray__filter removes some of the fds the 'pos1,pos2,pos3'
>>>>> indexes are not relevant anymore
>>>
>>> and that is why the return value of fdarray__add() should be converted
>>> to bool (added/not added). Currently the return value is used as bool
>>> only allover the calling code.
>>>
>>> fdarray__add_fixed() brings the notion of fd with fixed pos which is
>>> valid after fdarray__add_fixed() call so the pos could be used to access
>>> pos fd poll status after poll() call.
>>>
>>> pos = fdarray__add_fixed(array, fd);
>>> fdarray_poll(array);
>>> revents = fdarray_fixed_revents(array, pos);
>>> fdarray__del(array, pos);
>>
>> So how is it about just adding _revents() and _del() for fixed fds with
>> correction of retval to bool for fdarray__add()?
>
> I don't like the separation for fixed and non-fixed fds,
> why can't we make generic?
Usage models are different but they want still to be parts of the same class
for atomic poll(). The distinction is filterable vs. not filterable.
The distinction should be somehow provided in API. Options are:
1. expose separate API calls like __add_nonfilterable(), __del_nonfilterable();
use nonfilterable quality in __filter() and __poll() and, perhaps, other internals;
2. extend fdarray__add(, nonfilterable) with the nonfilterable quality
use the type in __filter() and __poll() and, perhaps, other internals;
expose less API calls in comparison with option 1
Exposure of pos for filterable fds should be converted to bool since currently
the returned pos can become stale and there is no way in API to check its state.
So it could look like this:
fdkey = fdarray__add(array, fd, events, type)
type: filterable, nonfilterable, somthing else
revents = fdarray__get_revents(fdkey);
fdarray__del(array, fdkey);
~Alexey
next prev parent reply other threads:[~2020-06-08 9:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 15:47 [PATCH v7 00/13] perf: support enable and disable commands in stat and record modes Alexey Budankov
2020-06-03 15:52 ` [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors Alexey Budankov
2020-06-05 10:50 ` Jiri Olsa
2020-06-05 11:38 ` Jiri Olsa
2020-06-05 16:15 ` Alexey Budankov
2020-06-08 8:08 ` Alexey Budankov
2020-06-08 8:43 ` Jiri Olsa
2020-06-08 9:54 ` Alexey Budankov [this message]
2020-06-08 15:05 ` Alexey Budankov
2020-06-08 16:07 ` Jiri Olsa
2020-06-08 16:43 ` Alexey Budankov
2020-06-08 17:18 ` Alexey Budankov
2020-06-09 14:56 ` Jiri Olsa
2020-06-09 18:51 ` Alexey Budankov
2020-06-15 13:13 ` Alexey Budankov
2020-06-15 17:38 ` Alexey Budankov
2020-06-15 5:20 ` Alexey Budankov
2020-06-15 12:30 ` Jiri Olsa
2020-06-15 14:37 ` Alexey Budankov
2020-06-15 16:58 ` Jiri Olsa
2020-06-17 9:27 ` Jiri Olsa
2020-06-17 9:39 ` Alexey Budankov
2020-06-22 9:47 ` Alexey Budankov
2020-06-22 10:21 ` Jiri Olsa
2020-06-22 10:50 ` Alexey Budankov
2020-06-22 12:11 ` Jiri Olsa
2020-06-22 14:04 ` Alexey Budankov
2020-06-23 14:54 ` Jiri Olsa
2020-06-05 11:50 ` Alexey Budankov
2020-06-03 15:53 ` [PATCH v7 02/13] perf evlist: introduce control " Alexey Budankov
2020-06-03 15:54 ` [PATCH v7 03/13] perf evlist: implement control command handling functions Alexey Budankov
2020-06-23 14:54 ` Jiri Olsa
2020-06-24 11:48 ` Alexey Budankov
2020-06-03 15:55 ` [PATCH v7 04/13] perf stat: factor out body of event handling loop for system wide Alexey Budankov
2020-06-03 15:56 ` [PATCH v7 05/13] perf stat: move target check to loop control statement Alexey Budankov
2020-06-03 15:57 ` [PATCH v7 06/13] perf stat: factor out body of event handling loop for fork case Alexey Budankov
2020-06-03 15:57 ` [PATCH v7 07/13] perf stat: factor out event handling loop into dispatch_events() Alexey Budankov
2020-06-03 15:58 ` [PATCH v7 08/13] perf stat: extend -D,--delay option with -1 value Alexey Budankov
2020-06-03 15:59 ` [PATCH v7 09/13] perf stat: implement control commands handling Alexey Budankov
2020-06-03 15:59 ` [PATCH v7 10/13] perf stat: introduce --ctl-fd[-ack] options Alexey Budankov
2020-06-03 16:00 ` [PATCH v7 11/13] perf record: extend -D,--delay option with -1 value Alexey Budankov
2020-06-03 16:01 ` [PATCH v7 12/13] perf record: implement control commands handling Alexey Budankov
2020-06-03 16:02 ` [PATCH v7 13/13] perf record: introduce --ctl-fd[-ack] options Alexey Budankov
2020-06-05 7:47 ` [PATCH v7 00/13] perf: support enable and disable commands in stat and record modes 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=2d80a43a-54cf-3d12-92fd-066217c95d76@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