All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Thu, 1 Sep 2016 18:56:24 +0200	[thread overview]
Message-ID: <20160901165624.GB13138@redhat.com> (raw)
In-Reply-To: <CAJwJo6aL5vG1k=WTtBJQZeD5esUU=6StiTPtYxLAt5Q40xDMOg@mail.gmail.com>

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 D!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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
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
Date: Thu, 1 Sep 2016 18:56:24 +0200	[thread overview]
Message-ID: <20160901165624.GB13138@redhat.com> (raw)
In-Reply-To: <CAJwJo6aL5vG1k=WTtBJQZeD5esUU=6StiTPtYxLAt5Q40xDMOg@mail.gmail.com>

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.

  parent reply	other threads:[~2016-09-01 16:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 13:59 [PATCHv4 0/6] x86: 32-bit compatible C/R on x86_64 Dmitry Safonov
2016-08-31 13:59 ` Dmitry Safonov
2016-08-31 13:59 ` [PATCHv4 1/6] x86/vdso: unmap vdso blob on vvar mapping failure Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 13:59 ` [PATCHv4 2/6] x86/vdso: replace calculate_addr in map_vdso() with addr Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 20:00   ` Andy Lutomirski
2016-08-31 20:00     ` Andy Lutomirski
2016-08-31 13:59 ` [PATCHv4 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_* Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 14:04   ` Dmitry Safonov
2016-08-31 14:04     ` Dmitry Safonov
2016-08-31 14:56     ` Andy Lutomirski
2016-08-31 14:56       ` Andy Lutomirski
2016-08-31 15:01       ` Dmitry Safonov
2016-08-31 15:01         ` Dmitry Safonov
2016-08-31 15:08         ` Andy Lutomirski
2016-08-31 15:08           ` Andy Lutomirski
2016-08-31 13:59 ` [PATCHv4 4/6] x86/coredump: use pr_reg size, rather that TIF_IA32 flag Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 13:59 ` [PATCHv4 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 13:59 ` [PATCHv4 6/6] x86/signal: add SA_{X32,IA32}_ABI sa_flags Dmitry Safonov
2016-08-31 13:59   ` Dmitry Safonov
2016-08-31 14:07   ` Dmitry Safonov
2016-08-31 14:07     ` Dmitry Safonov
2016-09-01 12:27     ` Oleg Nesterov
2016-09-01 12:27       ` Oleg Nesterov
2016-09-01 12:45       ` Cyrill Gorcunov
2016-09-01 12:45         ` Cyrill Gorcunov
2016-09-01 13:47         ` Dmitry Safonov
2016-09-01 13:47           ` Dmitry Safonov
2016-09-01 13:59           ` Cyrill Gorcunov
2016-09-01 13:59             ` Cyrill Gorcunov
2016-09-01 16:56           ` Oleg Nesterov [this message]
2016-09-01 16:56             ` Oleg Nesterov
2016-09-01  6:18 ` [PATCHv4 0/6] x86: 32-bit compatible C/R on x86_64 Ingo Molnar
2016-09-01  6:18   ` Ingo Molnar
2016-09-01  8:19   ` Dmitry Safonov
2016-09-01  8:19     ` Dmitry Safonov

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=20160901165624.GB13138@redhat.com \
    --to=oleg@redhat.com \
    --cc=0x7f454c46@gmail.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=gorcunov@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.