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@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> -- Kind regards, Minchan Kim -- 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>