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

On 02/22/2017 10:54 AM, Cyrill Gorcunov wrote:

On Wed, Feb 22, 2017 at 10:44:07AM +0300, Pavel Emelyanov wrote:

quoted

On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote:

quoted

On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote:

quoted

quoted

Thus lets add file position, inode and device number where
this target lays. This three fields can be used as a primary
key for sorting, and together with kcmp help CRIU can find
out an exact file target (from the whole set of processes
being checkpointed).

I have no problem with this, but I'm wondering whether kcmp's ordered
comparisons could also be used for this purpose.

Yes it can, but it would increas number of kcmp calls signisicantly.

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.

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.

-- Pavel