Messages in this thread | | | Date | Mon, 22 Jun 2020 14:11:20 +0200 | From | Jiri Olsa <> | Subject | Re: [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors |
| |
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
| |