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

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

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.

Look, here is how we build files tree in criu: we take inode^sdev^pos
as a primary key and remember it inside rbtree while we're dumping files
(note also that we don't keep files opened but rather dump them in
chunks). Then once we find that two files have same primary key
we use kcmp to build subtree. This really helps a lot. And I plan
to do the same with target files from epolls:

 - they gonna be handled after all opened files of all processes
   in container (or children processes if dumping single task),
   thus the complete tree with primary key already will be built

 - on every target file I calculate primary key and then using
   kcmp will find if file is exactly one matching
.