linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linuxfoundation.org>,
	Andrew Vagin <avagin@virtuozzo.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Kirill Kolyshkin <kir@openvz.org>,
	Jason Baron <jbaron@akamai.com>, Andrey Vagin <avagin@openvz.org>
Subject: Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files
Date: Tue, 21 Feb 2017 22:16:55 +0300	[thread overview]
Message-ID: <20170221191655.GC27653@uranus> (raw)
In-Reply-To: <CALCETrUJcMuLpcLf5iQurGCnA1hqVH5YtHAq+=f81PF1OZy1Fg@mail.gmail.com>

On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote:
> > 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.
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

  reply	other threads:[~2017-02-21 19:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 16:59 [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files Cyrill Gorcunov
2017-02-21 18:41 ` Andy Lutomirski
2017-02-21 19:16   ` Cyrill Gorcunov [this message]
2017-02-22  7:44     ` Pavel Emelyanov
2017-02-22  7:54       ` Cyrill Gorcunov
2017-02-22  8:09         ` Pavel Emelyanov
2017-02-22  8:18           ` Cyrill Gorcunov
2017-02-22  8:29             ` Pavel Emelyanov
2017-02-22  8:35               ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170221191655.GC27653@uranus \
    --to=gorcunov@gmail.com \
    --cc=akpm@linuxfoundation.org \
    --cc=avagin@openvz.org \
    --cc=avagin@virtuozzo.com \
    --cc=jbaron@akamai.com \
    --cc=kir@openvz.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mtk.manpages@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).