Re: Change soft-dirty interface?

[Minchan Kim <minchan@kernel.org>]

Hello Pavel,

On Thu, Jun 13, 2013 at 01:10:50PM +0400, Pavel Emelyanov wrote:
> On 06/13/2013 05:53 AM, Minchan Kim wrote:
> > Hi all, 
> > 
> > Sorry for late interrupting to promote patchset to the mainline.
> > I'd like to discuss our usecase so I'd like to change per-process
> > interface with per-range interface.
> > 
> > Our usecase is following as,
> > 
> > A application allocates a big buffer(A) and makes backup buffer(B)
> > for it and copy B from A.
> > Let's assume A consists of subranges (A-1, A-2, A-3, A-4).
> > As time goes by, application can modify anywhere of A.
> > In this example, let's assume A-1 and A-2 are modified.
> > When the time happen, we compare A-1 with B-1 to make
> > diff of the range(On every iteration, we don't need all range's diff by design)
> > and do something with diff, then we'd like to remark only the A-1 with
> > soft-dirty, NOT A's all range of the process to track the A-1's
> > further difference in future while keeping dirty information (A-2, A-3, A-4)
> > because we will make A-2's diff in next iteration.
> > 
> > We can't do it by existing interface.
> 
> So you need to track changes not in the whole range, but in sub-ranges.
> OK.

Right.

> 
> > So, I'd like to add [addr, len] argument with using proc
> > 
> >     echo 4 0x100000 0x3000 > /proc/self/clear_refs
> > 
> > It doesn't break anything but not sure everyone like the interface
> > because recently I heard from akpm following comment.
> > 
> >         https://lkml.org/lkml/2013/5/21/529
> > 
> > Although per-process reclaim is another story with this,
> > I feel he seems to hate doing something on proc interface with
> > /proc/pid/maps like above range parameter.
> > 
> > If it's not allowed, another approach should be new system call.
> > 
> >         int sys_softdirty(pid_t pid, void *addr, size_t len);
> 
> This looks like existing sys_madvise() one.

Except pid part. It is added by your purpose, which external task
can control any process.

> 
> > If we approach new system call, we don't need to maintain current
> > proc interface and it would be very handy to get a information
> > without pagemap (open/read/close) so we can add a parameter to
> > get a dirty information easily.
> > 
> >         int sys_softdirty(pid_t pid, void *addr, size_t len, unsigned char *vec)
> > 
> > What do you think about it?
> > 
> 
> This is OK for me, though there's another issue with this API I'd like
> to mention -- consider your app is doing these tricks with soft-dirty
> and at the same time CRIU tools live-migrate it using the soft-dirty bits
> to optimize the freeze time.
> 
> In that case soft-dirty bits would be in wrong state for both -- you app
> and CRIU, but with the proc API we could compare the ctime-s of the 
> clear_refs file and find out, that someone spoiled the soft-dirty state
> from last time we messed with it and handle it somehow (copy all the memory
> in the worst case). Can we somehow handle this with your proposal?

Good point I didn't think over that.
A simple idea popped from my mind is we can use read/write lock
so if pid is equal to calling process's one or pid is NULL,
we use read side lock, which can allow marking soft-dirty 
several vmas with parallel. And pid is not equal to calling
process's one, the API should try to hold write-side lock
then, if it's fail, the API should return EAGAIN so that CRIU
can progress other processes and retry it after a while.
Of course, it would make live-lock so that sys_softdirty might
need another argument like "int block".

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

-- 
Kind regards,
Minchan Kim

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