>>> Maybe do you have a concern about live-lock? >> >> No, I worry about potential races with which we or application can skip >> dirty page. Let me describe how CRIU uses existing soft-dirty implementation. >> >> 1. stop the task we want to work on >> 2. read the /proc/pid/pagemap file to find out which pages to >> read. Those with soft-dirty _cleared_ should be _skipped_ >> 3. read task's memory at calculated bitmap >> 4. reset soft dirty bits on task >> 5. resume task execution > > Let me try to parse as my term. > > 1. admin does "echo 4 > /proc/<target>/clear_refs" > 2. admin stop the target > 3. admin reads the /proc/<target>/pagemap and make bitmap > with only soft-dirty marked pages so we can avoid unnecessary > migration > 4. admin reads target's dirtied pages via bitmap from 3 > 5. admin does "echo 4 > /proc/<target>/clear_refs" again to find > future diry pages of the target. > 6. admin resumes the target > > Right? Almost, the step #1 looks excessive. We shouldn't clear the soft dirty _before_ stopping the target, otherwise we lose all the bits "collected" before it. > If so, my interface is following as > > 1. admin does set_softdirty(target, 0, 0, &token); > (set_softdirty clears all soft-dirty bit from target process's > page table. > 2. admin stop the target > 3. admin reads the /proc/target/pagemap and make bitmap > with only soft-dirty marked pages so we can avoid unnecessary > migration. > 4. admins does get_softdirty(target, 0, 0, token) to confirm > someone else spoiled since 1 > 4-1. If it is reports error, then admins discard the bitmap got > from 3 and have to read all memory. > 5. admin does set_softdirty(target, 0, 0, &token) again to find > future dirty pages of the target > 5. admin resumes the target. Same here -- if we skip step #1, then we can merge steps 4 and 5 into one system call. Can we? >> >> With the interface you propose the sequence presumably should look like >> >> 1. stop the task we want to work on >> 2. call set_softdirty + get_softdirty to get the soft-dirty bitmap and >> reset one. If it reports error, then the soft-dirty we did before is >> spoiled and all memory should be read (iow -- bitmap should be filled >> with 1-s) >> 3. read task's memory at calculated bitmap >> 4. resume task execution > >> >> Am I right with this? If yes, why do we need two calls, wouldn't it be better > > I failed to parse your terms so I wrote scnario as my understanding > so please see my above sequence and if you have a comment, please ask > again. > >> to merge them into one? > > It's not hard part but I wanted to show my intention clearly. > If we all agree on, let's think over interface again. For me the interface with a single syscall looks OK. If nobody else objects, I think you can go on with the kernel patches :) Presumably you can even use the criu project sources and tests to check how memory changes tracking works with the new interface. > Thanks! Thanks, Pavel -- 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>