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

On Wed, Feb 22, 2017 at 11:29:23AM +0300, Pavel Emelyanov wrote:

On 02/22/2017 11:18 AM, Cyrill Gorcunov wrote:

quoted

On Wed, Feb 22, 2017 at 11:09:23AM +0300, Pavel Emelyanov wrote:

quoted

quoted

quoted

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.

quoted

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.

You read fdinfo per-epoll, but kcmp-s we're talking here are about per-target-files.
So having dev:ino pair would help to reduce the number of kcmps, but even w/o
this extension we can work OK.

I didn't say we can't. But since we're reading fdinfo anyway it will help I don't
see a single reason why should not we take this opportunity to speedup.

Besides, in most of the cases fd number you'd read from epoll's fdinfo will actually
be present in task's fdtable, so you can call a single kcmp, make sure the file is
correct and that's it. The need to actually _search_ for the runaway file with the
set of kcmp will (should) be quite rare case.

Yes. But this rare cases are the reason why I started this series :( I would
love to not add new code at all but simply had to.