Re: [PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file

2013-05-04 Thread Pavel Emelyanov
On 05/02/2013 09:08 PM, Matt Helsley wrote: > On Thu, Apr 11, 2013 at 03:29:41PM +0400, Pavel Emelyanov wrote: >> This file is the same as the pagemap one, but shows entries with bits >> 55-60 being zero (reserved for future use). Next patch will occupy one >> of them. > > This approach doesn't sc

Re: [PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file

2013-05-03 Thread Matt Helsley
On Thu, Apr 11, 2013 at 03:29:41PM +0400, Pavel Emelyanov wrote: > This file is the same as the pagemap one, but shows entries with bits > 55-60 being zero (reserved for future use). Next patch will occupy one > of them. This approach doesn't scale as well as it could. As best I can see CRIU would

Re: [PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file

2013-04-12 Thread Pavel Emelyanov
On 04/12/2013 01:19 AM, Andrew Morton wrote: > On Thu, 11 Apr 2013 15:29:41 +0400 Pavel Emelyanov > wrote: > >> This file is the same as the pagemap one, but shows entries with bits >> 55-60 being zero (reserved for future use). Next patch will occupy one >> of them. > > I'm not understanding t

Re: [PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file

2013-04-11 Thread Andrew Morton
On Thu, 11 Apr 2013 15:29:41 +0400 Pavel Emelyanov wrote: > This file is the same as the pagemap one, but shows entries with bits > 55-60 being zero (reserved for future use). Next patch will occupy one > of them. I'm not understanding the motivation for this. What does the current /proc/pid/pa

[PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file

2013-04-11 Thread Pavel Emelyanov
This file is the same as the pagemap one, but shows entries with bits 55-60 being zero (reserved for future use). Next patch will occupy one of them. Signed-off-by: Pavel Emelyanov --- Documentation/filesystems/proc.txt |2 ++ Documentation/vm/pagemap.txt |3 +++ fs/proc/base.c