From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753826AbcIAVNP (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Sep 2016 17:13:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40590 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753507AbcIAVNH (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Sep 2016 17:13:07 -0400
Date: Thu, 1 Sep 2016 18:56:24 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
        Dmitry Safonov <dsafonov@virtuozzo.com>, linux-kernel@vger.kernel.org,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>,
        Ingo Molnar <mingo@redhat.com>, linux-mm@kvack.org,
        X86 ML <x86@kernel.org>, Pavel Emelyanov <xemul@virtuozzo.com>
Subject: Re: [PATCHv4 6/6] x86/signal: add SA_{X32,IA32}_ABI sa_flags
Message-ID: <20160901165624.GB13138@redhat.com>
References: <20160831135936.2281-1-dsafonov@virtuozzo.com> <20160831135936.2281-7-dsafonov@virtuozzo.com> <CAJwJo6YZEN75XB8YaMS26rbFAR0x77B-gfLKv37ib_eB_OLMBg@mail.gmail.com> <20160901122744.GA7438@redhat.com> <20160901124522.GK23045@uranus.lan> <CAJwJo6aL5vG1k=WTtBJQZeD5esUU=6StiTPtYxLAt5Q40xDMOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJwJo6aL5vG1k=WTtBJQZeD5esUU=6StiTPtYxLAt5Q40xDMOg@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 01 Sep 2016 16:57:00 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/01, Dmitry Safonov wrote:
>
> And the biggest problem in this approach would be not the size of
> code changes to CRIU (which are already quite large with this
> patches set), but AFAICS, it will have big performance penalty:
> we would need to bounce process tree, processes properties
> from parent-CRIU to child-CRIU after exec() call and down on
> the processes hierarchy, recreating processes while synchronizing
> process's data from images.
>
> As for now, we already have time-critical problems in СRIU and
> we try to reduce the number of system calls, while it's still slow
> at some places. But that approach will lead to:
> o exec different CRIU
> o initialize it (i.e, parse /proc/self/maps to know it's vmas)
> o transphere process tree, for each process it's properties with IPC
>    after exec()
> It will all go for a large number of syscalls in total.

I do not really understand why it has to be so complicated, but
I can be easily wrong.

> And this arch_prctl() API is visible under CHECKPOINT_RESTORE
> config option, so will not bother anyone.

I mostly dislike 6/6. This new feauture looks a bit strange to me.

Nevermind, let me repeat once again, I am not trying to argue with
this series. No objections from me.

Oleg.