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