Re: [PATCH 04/10] perf record: Filter out POLLHUP'ed file descriptors

[Arnaldo Carvalho de Melo]

Em Sat, Sep 06, 2014 at 10:39:15PM +0200, Jiri Olsa escreveu:
> On Fri, Sep 05, 2014 at 11:07:56AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Sep 05, 2014 at 11:42:59AM +0300, Adrian Hunter escreveu:
> > > On 09/04/2014 06:19 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Sep 04, 2014 at 03:32:08PM +0300, Adrian Hunter escreveu:
> > > No I was meaning something different. For example, 'perf record' opens an
> > > event for 2 processes per-cpu and gets 4 file descriptors:

> > > 	task1	task2
> > > cpu0	fd0	fd1
> > > cpu1	fd2	fd3

> > > Now, perf record will mmap fd0 and fd2 and set-output fd1->fd0
> > > and fd3->fd2.

> > > pollfds includes only fd0 and fd2.

> > > But if task2 exits, the POLLHUP will appear on fd1 and fd3.

> > So? We are not interested in fd1 and fd3, since all our reading is done
> > on fd0 and fd2 mmaps, no?

> hm, what if task1 (fd0, fd2) exits first.. perf record will exit,
> but it still has to read task2..?

Ok, what happens in that case, i.e. when the fds that were set to be the
ones to be polled, gets nuked, does the set-output command gets just
undone? Or does the mmap stands, receiving the events from the remaining
fds and the polling notifications get sent to, in this case, fd3 and
fd1?

I'll look at the kernel code for that...
 
> > I.e. when we ask the kernel to point fd B to fd A's mmap (what you
> > called set-output) and fd B inserts an event into fd A's mmap ring
> > buffer, we get fd A poll return as POLLRD, no?

> > Have to check... Otherwise we would have to poll all fds all the time,
> > not just the ones mmaping, right?

> > > I think Jiri's patchset changed pollfds to include all fds for that reason.

> hm, I did not think of that.. ;-) I needed more grained feedback
> for future features like cpu hotplug

So this is good for something you didn't tried to fix (and document) but
good for something that may be nice in the future? Grumpf, we have
already way too much stuff that will be eventually used but is not used
right now :-\
 
> > It did? I have to look again, probably went together with other changes,
> > has it?
> 
> it was done by replacing 'int' with 'struct poll_item' for evsel::fd xyarray

Well, will look into that as soon as I see the need for it. I.e. after I
clarify the discussion above.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/