linux-cr ported to 3.2-rc1
I have ported the linux-cr patches from www.linux-cr.org/pub/git/linux-cr.git to the latest kernel (3.2-rc1). The tests (on x86_64) I have done so far were successful. My repository with the C/R patches on top of 3.2-rc1 is currently at:
http://lisas.de/~adrian/linux-cr.git
The development on the linux-cr tree hast stopped sometime around 2.6.37 and although those patches have gone through many revisions I am not sure about the latest state of those patches concerning inclusion. At what point has the discussion stopped and why?
I have seen patches from Pavel about another approach for checkpointing/restarting but I haven't heard anything about that during the last months.
What are the chances to get one of the checkpointing/restarting implementations included. What is still missing from the one I used? What is the latest state of Pavel's patches?
Adrian
Quoted 5 lines · Adrian Reber
I have ported the linux-cr patches from www.linux-cr.org/pub/git/linux-cr.git to the latest kernel (3.2-rc1). The tests (on
x86_64) I have done so far were successful. My repository with the C/R patches on top of 3.2-rc1 is currently at:
Quoted 7 lines
http://lisas.de/~adrian/linux-cr.git
The development on the linux-cr tree hast stopped sometime around 2.6.37 and although those patches have gone through many revisions I am not sure about the latest state of those patches concerning inclusion. At what point has the discussion stopped and why?
AFAIK very few people from the community support the idea of having the C/R functionality implemented as the kernel subsystem.
Quoted 6 lines
I have seen patches from Pavel about another approach for checkpointing/restarting but I haven't heard anything about that during the last months.
What are the chances to get one of the checkpointing/restarting implementations included. What is still missing from the one I used?
The chances are ... quite high. We implement our C/R code in the userspace and require very few pieces from kernel. So far 2 out of 3 proposed API extensions were merged into -mm tree.
Quoted 1 line
What is the latest state of Pavel's patches?
The state right now is - we can dump and restore tasks with any types of memory, open regular files and pipes with its contents. The code is currently under internal review process. We're going to send the public RFC early next week. Then go on with more resources to dump and restore.
Quoted 3 lines
Adrian
.
Quoted 21 lines · Pavel Emelyanov
Quoted 5 lines · Adrian Reber
I have ported the linux-cr patches from www.linux-cr.org/pub/git/linux-cr.git to the latest kernel (3.2-rc1). The tests (on
x86_64) I have done so far were successful. My repository with the C/R patches on top of 3.2-rc1 is currently at:Quoted 7 lines
http://lisas.de/~adrian/linux-cr.git
The development on the linux-cr tree hast stopped sometime around 2.6.37 and although those patches have gone through many revisions I am not sure about the latest state of those patches concerning inclusion. At what point has the discussion stopped and why?
AFAIK very few people from the community support the idea of having the C/R functionality implemented as the kernel subsystem.
Quoted 4 lines
I have seen patches from Pavel about another approach for checkpointing/restarting but I haven't heard anything about that during the last months.
Quoted 6 lines
Quoted 2 lines
What are the chances to get one of the checkpointing/restarting implementations included. What is still missing from the one I used?
The chances are ... quite high. We implement our C/R code in the userspace and require very few pieces from kernel. So far 2 out of 3 proposed API extensions were merged into -mm tree.
Hi Pavel,
does '2 out of 3 proposed' mean '2 out of 3 needed for full c/r support'? (That was the implication, and would be great) If not, the how many more api extensions would you foresee needed for that?
Quoted 16 lines
Quoted 1 line
What is the latest state of Pavel's patches?
The state right now is - we can dump and restore tasks with any types of memory, open regular files and pipes with its contents. The code is currently under internal review process. We're going to send the public RFC early next week. Then go on with more resources to dump and restore.
Quoted 3 lines
Adrian
.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines
Quoted 3 lines
The chances are ... quite high. We implement our C/R code in the userspace and require very few pieces from kernel. So far 2 out of 3 proposed API extensions were merged into -mm tree.
Hi Pavel,
does '2 out of 3 proposed' mean '2 out of 3 needed for full c/r support'?
No, for the c/r of process tree with any types of memory, open files and pipes.
Quoted 9 lines · Pavel Emelyanov
Quoted 8 lines · Adrian Reber
I have ported the linux-cr patches from www.linux-cr.org/pub/git/linux-cr.git to the latest kernel (3.2-rc1). The tests (on
x86_64) I have done so far were successful. My repository with the C/R patches on top of 3.2-rc1 is currently at:
Quoted 7 lines
Quoted 4 lines
The development on the linux-cr tree hast stopped sometime around 2.6.37 and although those patches have gone through many revisions I am not sure about the latest state of those patches concerning inclusion. At what point has the discussion stopped and why?
AFAIK very few people from the community support the idea of having the C/R functionality implemented as the kernel subsystem.
Ah. Okay. I still ported those patches to 3.2 so that there exists a working C/R until you have released your code.
http://lisas.de/~adrian/cr/3.2/linux-cr.git
Quoted 11 lines
Quoted 6 lines
I have seen patches from Pavel about another approach for checkpointing/restarting but I haven't heard anything about that during the last months.
What are the chances to get one of the checkpointing/restarting implementations included. What is still missing from the one I used?
The chances are ... quite high. We implement our C/R code in the userspace and require very few pieces from kernel. So far 2 out of 3 proposed API extensions were merged into -mm tree.
Quoted 6 lines
Quoted 1 line
What is the latest state of Pavel's patches?
The state right now is - we can dump and restore tasks with any types of memory, open regular files and pipes with its contents. The code is currently under internal review process. We're going to send the public RFC early next week. Then go on with more resources to dump and restore.
I am interested in C/R and if your code has better chances going upstream then I would be interested seeing those patches and working with you. As long as I do not have your code I will keep on working with the patches I currently have and which seem to be running pretty good on 3.2 so far.
The first set of patches in my current patchset tries to implement eclone() which provides the clone() functionality but with the possibility to request a certain PID so that child processes can be restarted with the same PID. How are you planning to restart child processes? Are those patches maybe something which makes also sense for your C/R implementation?
Adrian
Quoted 5 lines
The first set of patches in my current patchset tries to implement
eclone()which provides theclone()functionality but with the possibility to request a certain PID so that child processes can be restarted with the same PID. How are you planning to restart child processes?
With the /proc/sys/kernel/ns_last_pid helper.
Quoted 1 line
Are those patches maybe something which makes also sense for your C/R implementation?
The sources are here:
Kernel with all the patches we want:
https://github.com/cyrillos/linux-2.6/tree/crtools
User-space part:
https://github.com/cyrillos/crtools
Documentation:
http://criu.org
Quoted 3 lines
Adrian
.