From: Jiri Olsa <jolsa@redhat.com>
To: Alexey Budankov <alexey.budankov@linux.intel.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, 22 Jun 2020 14:11:20 +0200 [thread overview]
Message-ID: <20200622121120.GA2584593@krava> (raw)
In-Reply-To: <cad3d9a6-da28-c627-de73-17169a7c36a1@linux.intel.com>
On Mon, Jun 22, 2020 at 01:50:03PM +0300, Alexey Budankov wrote:
>
> On 22.06.2020 13:21, Jiri Olsa wrote:
> > On Mon, Jun 22, 2020 at 12:47:19PM +0300, Alexey Budankov wrote:
> >
> > SNIP
> >
> >>>>>>>> fdarray__del(array, fdkey);
> >>>>>>>
> >>>>>>> I think there's solution without having filterable type,
> >>>>>>> I'm not sure why you think this is needed
> >>>>>>>
> >>>>>>> I'm busy with other things this week, but I think I can
> >>>>>>> come up with some patch early next week if needed
> >>>>>>
> >>>>>> Friendly reminder.
> >>>>>
> >>>>> hm? I believe we discussed this in here:
> >>>>> https://lore.kernel.org/lkml/20200609145611.GI1558310@krava/
> >>>>
> >>>> Do you want it to be implemented like in the patch posted by the link?
> >>>
> >>> no idea.. looking for good solution ;-)
> >>>
> >>> how about switching completely to epoll? I tried and it
> >>> does not look that bad
> >>
> >> Well, epoll() is perhaps possible but why does it want switching to epoll()?
> >> What are the benefits and/or specific task being solved by this switch?
> >
> > epoll change fixes the same issues as the patch you took in v8
> >
> > on top of it it's not a hack and wil make polling more user
> > friendly because of the clear interface
>
> Clear. The opposite thing is /proc/sys/fs/epoll/max_user_watches limit that
> will affect Perf tool usage additionally to the current process limit on
> a number of simultaneously open file descriptors (ulimit -n). So move to
> epoll() will impose one limit what can affect Perf tool scalability.
hum, I dont think this will be a problem:
Allowing top 4% of low memory (per user) to be allocated in epoll watches,
we have:
LOMEM MAX_WATCHES (per user)
512MB ~178000
1GB ~356000
2GB ~712000
my laptop has 19841945 allowed watches per user
>
> >
> >>
> >>>
> >>> there might be some loose ends (interface change), but
> >>> I think this would solve our problems with fdarray
> >>
> >> Your first patch accomodated in v8 actually avoids fds typing
> >> and solves pos (=fdarray__add()) staleness issue with fdarray.
> >
> > yea, it was a change meant for discussion (which never happened),
> > and I considered it to be more a hack than a solution
> >
> > I suppose we can live with that for a while, but I'd like to
> > have clean solution for polling as well
>
> I wouldn't treat it as a hack but more as a fix because returned
> pos is now a part of interface that can be safely used in callers.
> Can we go with this fix for the patch set?
apart from this one I still have a problem with that stat factoring
having 1 complicated function deal with both fork and no fork processing,
which I already commented on, but you ignored ;-)
I'll try to go through that once more, and post some comments
jirka
next prev parent reply other threads:[~2020-06-22 12:11 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
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 [this message]
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=20200622121120.GA2584593@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.budankov@linux.intel.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;
as well as URLs for NNTP newsgroup(s).