Re: Change soft-dirty interface?

[Pavel Emelyanov <xemul@parallels.com>]

>>> 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@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>