Checkpoint/restart tries to head towards the mainline Mar 15, 2009

http://lwn.net/Articles/320508/

Checkpoint/restart가 벌써 v13이다.
barrios가 처음 이 패치를 review했던 것이 08년 9월이니 벌써 6달이 지났다.
그 후로 몇번의 review요청이 왔었으나 다른 일들로 follow up하지 못하고 있었다.

그동안 Oren은 Hansen과 함께 이 패치를 계속해서 improve시켜왔다.
하지만 Checkpoint/restart는 결코 가벼운 패치가 아니다. 제대로 동작하기 위해서는 커널 전반에 걸쳐 많은 core function들의 수정이 불가피하다.

Oran은 이 패치가 mm에 merge되기를 바라고 있지만, Andrew는 여러 이유로 그것을 받아들이지 않고 있다.

첫째로, 아직까지 toy 수준의 이러한 패치를 merge하게 된다면, 결곡 non-toy로 만들기 위해 받아들일 수 없을 정도로 비용이 큰 패치들을 계속해서 받아들여아 하거나.
돌째로, 그러한 패치를 받아들이지 않아서 계속해서 toy로 남게 하거나,
셋째로, 현재 빠져 있는 기능들에 대해서 그것들을 어떻게 구현하여 해결할지에 대해서 논의되지 않았다는 이유이다.

현재 Checkpoint/restart는 매우 제한된 app에서만 동작할 수 있다.
프로세스는 single thread여야 하며, fd operation은 open, lseek 정도만 restore될 수 있고, Shared memory, hugetlbfs, VM_NONLINEAR 등은 지원하지 못하고 있는 수준이다.
이 밖에도 Dave Hansen은 여러 문제들을 자세히 나열하였다.

하지만, 현재 어떤 기능이 구현되어 있느냐보다 더욱 중요한 문제는 현재로서 어떤 해결책도 없는 문제이거나 커널을 많이 고쳐야만 풀릴 수 있는 잠재적인 문제들이 있다는 것이다.

기술적인 문제를 하나 소개하자면, 다음과 같은 문제가 있다.
프로세스들이 어떻게 자신의 state가 checkpointable 한지를 결정하냐는 것이다.
Ingo는 이 문제에 대해서 LSM security checks를 overloading하여 checkpointable 여부를 결정할 수 있는 flag를 사용하자는 것이다. 이 flag는 해당 app나 checkpoint시키길 원하는 프로세스들에게 노출시킬 수 있다는 것이다. 하지만 많은 사람들은 LSM의 많은 hook에 대한 overhead를 걱정하고 있다.

이에 대한 또 다른 concern은 이 flag의 setting을 one-way로 하는 것이 바람직하냐는 것이다. 이 문제는 현재의 LSM hook의 문제이다. 현재의 LSM hook은 open은 검사하지만 close는 검사하지 않는 다는 것이다. 그러므로 다시 checkpointable 한 state가 되는 것을 알 수 없다는 것이다. 이에 대해 Ingo는 one-way flag가 맞는 방향이라고 얘기하고 있다. 그래서 Checkpoint를 사용하는 많은 user들로 하여금 커널의 uncheckpointable한 operation들에 대해 압력을 행사하도록 하여 수정을 유도하는 것이 좋다는 것이다.

Checkpoint를 구현한 Opensource 프로젝트들이 다수 있지만 Oran과 Hansen은 그러한 오픈 소스 프로젝트들을 잘 이용하면 자신들의 구현이 훨씬 뛰어날 수 있다고 말하고 있으며, 반면, 커널 전반에 많은 수정을 가하게 될 이 패치를 Andrew는 아직 걱정하고 있다.

계속해서 노력한다면 언젠가 merge가 되겠지만, barrios의 생각은 이 패치의 merge여부를 떠나 앞으로 이 패치를 지켜보면 커널 전반을 이해하기 위한 좋은 예제가 되지 않을까 하는 것이다. ^^