From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db5eur01on0130.outbound.protection.outlook.com ([104.47.2.130]:23271 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751192AbdBVHoU (ORCPT ); Wed, 22 Feb 2017 02:44:20 -0500 Subject: Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files To: Cyrill Gorcunov , Andy Lutomirski References: <20170221171254.954209904@openvz.org> <20170221191655.GC27653@uranus> CC: Linux FS Devel , "linux-kernel@vger.kernel.org" , Linux API , Al Viro , Andrew Morton , Andrew Vagin , Michael Kerrisk , Kirill Kolyshkin , Jason Baron , Andrey Vagin From: Pavel Emelyanov Message-ID: <58AD4147.20801@virtuozzo.com> Date: Wed, 22 Feb 2017 10:44:07 +0300 MIME-Version: 1.0 In-Reply-To: <20170221191655.GC27653@uranus> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote: > 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. 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 > . >