Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

[Cyrill Gorcunov <gorcunov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Wed, Feb 22, 2017 at 11:09:23AM +0300, Pavel Emelyanov wrote:
> >>
> >> Actually it shouldn't. If you extend the kcmp argument to accept the
> >> epollfd:epollslot pair, this would be effectively the same as if you
> >> had all your epoll-ed files injected into your fdtable with "strange"
> >> fd numbers. We already have two-level rbtree for this in criu, adding
> >> extended ("strange") fd to it should be OK.
> > 
> > Nope. Pavel, I guess you forget how we handle file tree in criu currently.
> > We call for kcmp only if we have to -- when primary key for two entries
> > is the same.
> 
> True, but the latter is an optimization to reduce the number of syscalls.

Exactly. While syscalls are quite effective, they are still not coming
for free, so I'm trying to reduce their number as much as possible.

> Look, in order to have a primary key you need to do some system call for the
> fd you check (read from proc or stat the descriptor). But for target files in
> e-polls you don't make this per-fd syscall to get primary key, just call the
> kcmp instead.

I have to parse fdinfo anyway, because I need to fetch queued events and mask.
So I'll _have_ to make this per-fd syscall for parsing. And this opens
a way to optimize overall picture -- we can immediately read primary
key and reduce kcmp calls.