numa_maps update

numa_maps update

[Christoph Lameter]

Change the format of numa_maps to be more compact and contain additional
information that is useful for managing and troubleshooting memory on a NUMA
system. Numa_maps can now also support huge pages.

Fixes:

1. More compact format. Only display fields if they contain additional
	information.

2. Always display information for all vmas. The old numa_maps did not display
	vma with no mapped entries. This was a bit confusing because page
	migration removes ptes for file backed vmas. After page migration
	a part of the vmas vanished.

3. Rename maxref to maxmap. This is the maximum mapcount of all the pages
	in a vma and may be used as an indicator as to how many processes
	may be using a certain vma.

4. Include the ability to scan over huge page vmas.

New items shown:

dirty
	Number of pages in a vma that have either the dirty bit set in the
	page_struct or in the pte.

file=<filename>
	The file backing the pages if any

stack
	Stack area

heap
	Heap area

huge
	Huge page area. The number of pages shows is the number of huge
	pages not the regular sized pages.

swapcache
	Number of pages with swap references. Must be >0 in order to
	be shown.

active
	Number of active pages. Only displayed if different from the number
	of pages mapped.

locked
	Number of pages locked. Only displayed if >0.

Sample ouput of a process using huge pages:

00000000 default
2000000000000000 default file=/lib/ld-2.3.90.so mapped=13 mapmax=30 N0=13
2000000000044000 default file=/lib/ld-2.3.90.so anon=2 dirty=2 swapcache=2 N2=2
2000000000064000 default file=/lib/librt-2.3.90.so mapped=2 active=1 N1=1 N3=1
2000000000074000 default file=/lib/librt-2.3.90.so
2000000000080000 default file=/lib/librt-2.3.90.so anon=1 swapcache=1 N2=1
2000000000084000 default
2000000000088000 default file=/lib/libc-2.3.90.so mapped=52 mapmax=32 active=48 N0=52
20000000002bc000 default file=/lib/libc-2.3.90.so
20000000002c8000 default file=/lib/libc-2.3.90.so anon=3 dirty=2 swapcache=3 active=2 N1=1 N2=2
20000000002d4000 default anon=1 swapcache=1 N1=1
20000000002d8000 default file=/lib/libpthread-2.3.90.so mapped=8 mapmax=3 active=7 N2=2 N3=6
20000000002fc000 default file=/lib/libpthread-2.3.90.so
2000000000308000 default file=/lib/libpthread-2.3.90.so anon=1 dirty=1 swapcache=1 N1=1
200000000030c000 default anon=1 dirty=1 swapcache=1 N1=1
2000000000320000 default anon=1 dirty=1 N1=1
200000000071c000 default
2000000000720000 default anon=2 dirty=2 swapcache=1 N1=1 N2=1
2000000000f1c000 default
2000000000f20000 default anon=2 dirty=2 swapcache=1 active=1 N2=1 N3=1
200000000171c000 default
2000000001720000 default anon=1 dirty=1 swapcache=1 N1=1
2000000001b20000 default
2000000001b38000 default file=/lib/libgcc_s.so.1 mapped=2 N1=2
2000000001b48000 default file=/lib/libgcc_s.so.1
2000000001b54000 default file=/lib/libgcc_s.so.1 anon=1 dirty=1 active=0 N1=1
2000000001b58000 default file=/lib/libunwind.so.7.0.0 mapped=2 active=1 N1=2
2000000001b74000 default file=/lib/libunwind.so.7.0.0
2000000001b80000 default file=/lib/libunwind.so.7.0.0
2000000001b84000 default
4000000000000000 default file=/media/huge/test9 mapped=1 N1=1
6000000000000000 default file=/media/huge/test9 anon=1 dirty=1 active=0 N1=1
6000000000004000 default heap
607fffff7fffc000 default anon=1 dirty=1 swapcache=1 N2=1
607fffffff06c000 default stack anon=1 dirty=1 active=0 N1=1
8000000060000000 default file=/mnt/huge/test0 huge dirty=3 N1=3
8000000090000000 default file=/mnt/huge/test1 huge dirty=3 N0=1 N2=2
80000000c0000000 default file=/mnt/huge/test2 huge dirty=3 N1=1 N3=2

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.16-rc5-mm2/mm/mempolicy.c
===================================================================
--- linux-2.6.16-rc5-mm2.orig/mm/mempolicy.c	2006-03-03 07:58:14.000000000 -0800
+++ linux-2.6.16-rc5-mm2/mm/mempolicy.c	2006-03-03 08:53:40.000000000 -0800
@@ -197,7 +197,7 @@ static struct mempolicy *mpol_new(int mo
 	return policy;
 }
 
-static void gather_stats(struct page *, void *);
+static void gather_stats(struct page *, void *, int pte_dirty);
 static void migrate_page_add(struct page *page, struct list_head *pagelist,
 				unsigned long flags);
 
@@ -239,7 +239,7 @@ static int check_pte_range(struct vm_are
 			continue;
 
 		if (flags & MPOL_MF_STATS)
-			gather_stats(page, private);
+			gather_stats(page, private, pte_dirty(*pte));
 		else if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL))
 			migrate_page_add(page, private, flags);
 		else
@@ -1785,67 +1785,143 @@ static inline int mpol_to_str(char *buff
 struct numa_maps {
 	unsigned long pages;
 	unsigned long anon;
-	unsigned long mapped;
+	unsigned long active;
+	unsigned long locked;
 	unsigned long mapcount_max;
+	unsigned long dirty;
+	unsigned long swapcache;
 	unsigned long node[MAX_NUMNODES];
 };
 
-static void gather_stats(struct page *page, void *private)
+static void gather_stats(struct page *page, void *private, int pte_dirty)
 {
 	struct numa_maps *md = private;
 	int count = page_mapcount(page);
 
-	if (count)
-		md->mapped++;
+	md->pages++;
+	if (pte_dirty || PageDirty(page))
+		md->dirty++;
 
-	if (count > md->mapcount_max)
-		md->mapcount_max = count;
+	if (PageSwapCache(page))
+		md->swapcache++;
 
-	md->pages++;
+	if (PageActive(page))
+		md->active++;
+
+	if (PageLocked(page))
+		md->locked++;
 
 	if (PageAnon(page))
 		md->anon++;
 
+	if (count > md->mapcount_max)
+		md->mapcount_max = count;
+
 	md->node[page_to_nid(page)]++;
 	cond_resched();
 }
 
+static void check_huge_range(struct vm_area_struct *vma,
+		unsigned long start, unsigned long end,
+		struct numa_maps *md)
+{
+	unsigned long addr;
+	struct page *page;
+
+	for (addr = start; addr < end; addr += HPAGE_SIZE) {
+		pte_t *ptep = huge_pte_offset(vma->vm_mm, addr & HPAGE_MASK);
+		pte_t pte;
+
+		if (!ptep)
+			continue;
+
+		pte = *ptep;
+		if (pte_none(pte))
+			continue;
+
+		page = pte_page(pte);
+		if (!page)
+			continue;
+
+		gather_stats(page, md, pte_dirty(*ptep));
+	}
+}
+
 int show_numa_map(struct seq_file *m, void *v)
 {
 	struct proc_maps_private *priv = m->private;
 	struct vm_area_struct *vma = v;
 	struct numa_maps *md;
+	struct file *file = vma->vm_file;
+	struct mm_struct *mm = vma->vm_mm;
 	int n;
 	char buffer[50];
 
-	if (!vma->vm_mm)
+	if (!mm)
 		return 0;
 
 	md = kzalloc(sizeof(struct numa_maps), GFP_KERNEL);
 	if (!md)
 		return 0;
 
-	if (!is_vm_hugetlb_page(vma))
+	mpol_to_str(buffer, sizeof(buffer),
+			get_vma_policy(priv->task, vma, vma->vm_start));
+
+	seq_printf(m, "%08lx %s", vma->vm_start, buffer);
+
+	if (file) {
+
+		seq_printf(m, " file=");
+		seq_path(m, file->f_vfsmnt, file->f_dentry, "\n\t");
+
+	} else if (vma->vm_start <= mm->brk &&
+		   vma->vm_end >= mm->start_brk)
+
+			seq_printf(m, " heap");
+
+	else if (vma->vm_start <= mm->start_stack &&
+		vma->vm_end >= mm->start_stack)
+
+			seq_printf(m, " stack");
+
+	if (is_vm_hugetlb_page(vma)) {
+
+		check_huge_range(vma, vma->vm_start, vma->vm_end, md);
+		seq_printf(m, " huge");
+
+	} else
 		check_pgd_range(vma, vma->vm_start, vma->vm_end,
 		    &node_online_map, MPOL_MF_STATS, md);
 
-	if (md->pages) {
-		mpol_to_str(buffer, sizeof(buffer),
-			    get_vma_policy(priv->task, vma, vma->vm_start));
-
-		seq_printf(m, "%08lx %s pages=%lu mapped=%lu maxref=%lu",
-			   vma->vm_start, buffer, md->pages,
-			   md->mapped, md->mapcount_max);
-
-		if (md->anon)
-			seq_printf(m," anon=%lu",md->anon);
-
-		for_each_online_node(n)
-			if (md->node[n])
-				seq_printf(m, " N%d=%lu", n, md->node[n]);
+	if (!md->pages)
+		goto out;
 
-		seq_putc(m, '\n');
-	}
+	if (md->anon)
+		seq_printf(m," anon=%lu",md->anon);
+
+	if (md->dirty)
+		seq_printf(m," dirty=%lu",md->dirty);
+
+	if (md->pages != md->anon && md->pages != md->dirty)
+		seq_printf(m, " mapped=%lu", md->pages);
+
+	if (md->mapcount_max > 1)
+		seq_printf(m, " mapmax=%lu", md->mapcount_max);
+
+	if (md->swapcache)
+		seq_printf(m," swapcache=%lu", md->swapcache);
+
+	if (md->active < md->pages && !is_vm_hugetlb_page(vma))
+		seq_printf(m," active=%lu", md->active);
+
+	if (md->locked)
+		seq_printf(m," locked=%lu", md->locked);
+
+	for_each_online_node(n)
+		if (md->node[n])
+			seq_printf(m, " N%d=%lu", n, md->node[n]);
+out:
+	seq_putc(m, '\n');
 	kfree(md);
 
 	if (m->count < m->size)

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

Re: numa_maps update

[Andi Kleen]

On Saturday 04 March 2006 10:07, Andrew Morton wrote:
> Christoph Lameter <clameter@engr.sgi.com> wrote:
> >
> > Change the format
> 
> uh-oh.

I guess it's better because it's clearly better than the old format.
But of course it would need to be done before 2.6.16
> 
> > of numa_maps to be more compact and contain additional
> > information that is useful for managing and troubleshooting memory on a NUMA
> > system. Numa_maps can now also support huge pages.
> 
> What will be the userspace impact (ie: breakage) due to this change?

It will at least break the manpages I think. But I suspect/hope no user space
is using it yet because it was only added recently.

> > +	if (file) {
> > +
> > +		seq_printf(m, " file=");
> > +		seq_path(m, file->f_vfsmnt, file->f_dentry, "\n\t");
> > +
> > +	} else if (vma->vm_start <= mm->brk &&
> > +		   vma->vm_end >= mm->start_brk)
> > +
> > +			seq_printf(m, " heap");
> > +
> > +	else if (vma->vm_start <= mm->start_stack &&
> > +		vma->vm_end >= mm->start_stack)
> > +
> > +			seq_printf(m, " stack");
> > +
> > +	if (is_vm_hugetlb_page(vma)) {
> > +
> > +		check_huge_range(vma, vma->vm_start, vma->vm_end, md);
> > +		seq_printf(m, " huge");
> > +
> > +	} else
> 
> What bizarre layout!

The 16 space indents?

-Andi

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

Re: numa_maps update

[Andrew Morton]

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> Change the format

uh-oh.

> of numa_maps to be more compact and contain additional
> information that is useful for managing and troubleshooting memory on a NUMA
> system. Numa_maps can now also support huge pages.

What will be the userspace impact (ie: breakage) due to this change?

> New items shown:
>
> ... 
> locked
> 	Number of pages locked. Only displayed if >0.

I doubt if the PageLocked() count will be useful.  The only occasion upon
which pages are locked for more than a fleeting period is when they're
initially being brought up to date from backing store - readahead, swapin,
etc.

A more useful statistic would be the number of PageWriteback() pages.

> +	if (file) {
> +
> +		seq_printf(m, " file=");
> +		seq_path(m, file->f_vfsmnt, file->f_dentry, "\n\t");
> +
> +	} else if (vma->vm_start <= mm->brk &&
> +		   vma->vm_end >= mm->start_brk)
> +
> +			seq_printf(m, " heap");
> +
> +	else if (vma->vm_start <= mm->start_stack &&
> +		vma->vm_end >= mm->start_stack)
> +
> +			seq_printf(m, " stack");
> +
> +	if (is_vm_hugetlb_page(vma)) {
> +
> +		check_huge_range(vma, vma->vm_start, vma->vm_end, md);
> +		seq_printf(m, " huge");
> +
> +	} else

What bizarre layout!

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

Re: numa_maps update

[Christoph Lameter]

On Sat, 4 Mar 2006, Andi Kleen wrote:

> > What will be the userspace impact (ie: breakage) due to this change?
> 
> It will at least break the manpages I think. But I suspect/hope no user space
> is using it yet because it was only added recently.

There are no manpages for numa_maps yet. The only uses I know of currently 
is users doing "cat /proc/<pid>/numa_maps".

> > What bizarre layout!
> 
> The 16 space indents?

The issue was the blank lines in there?

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

Re: numa_maps update

[Andrew Morton]

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> On Sat, 4 Mar 2006, Andi Kleen wrote:
> 
> > > What will be the userspace impact (ie: breakage) due to this change?
> > 
> > It will at least break the manpages I think. But I suspect/hope no user space
> > is using it yet because it was only added recently.
> 
> There are no manpages for numa_maps yet. The only uses I know of currently 
> is users doing "cat /proc/<pid>/numa_maps".

hm, OK.

What about the PageLocked() accounting?  Do you really think that's
necessary?  Should we change it to (or add) PageWriteback() accounting?

> > > What bizarre layout!
> > 
> > The 16 space indents?
> 
> The issue was the blank lines in there?

mainly.

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

Re: numa_maps update

[Christoph Lameter]

On Sat, 4 Mar 2006, Andrew Morton wrote:

> What about the PageLocked() accounting?  Do you really think that's
> necessary?  Should we change it to (or add) PageWriteback() accounting?

I will add pagewriteback accounting. Pagelocked is useful to see an 
an ongoing migration but we can remove that.

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

Re: numa_maps update

[Christoph Lameter]

1. Remove pagelocked display. Worked only sporadically for page 
   migration.

2. Add writeback display as requested by Andrew

3. Escape some more characters when displaying filenames so that a program
   can parse or skip the filename in a reasonable way.

Andi: will try to get you a manpage later today to be included in the 
numactl package.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.16-rc5-mm2/mm/mempolicy.c
===================================================================
--- linux-2.6.16-rc5-mm2.orig/mm/mempolicy.c	2006-03-06 09:10:13.000000000 -0800
+++ linux-2.6.16-rc5-mm2/mm/mempolicy.c	2006-03-06 09:12:50.000000000 -0800
@@ -1786,7 +1786,7 @@ struct numa_maps {
 	unsigned long pages;
 	unsigned long anon;
 	unsigned long active;
-	unsigned long locked;
+	unsigned long writeback;
 	unsigned long mapcount_max;
 	unsigned long dirty;
 	unsigned long swapcache;
@@ -1808,8 +1808,8 @@ static void gather_stats(struct page *pa
 	if (PageActive(page))
 		md->active++;
 
-	if (PageLocked(page))
-		md->locked++;
+	if (PageWriteback(page))
+		md->writeback++;
 
 	if (PageAnon(page))
 		md->anon++;
@@ -1871,7 +1871,7 @@ int show_numa_map(struct seq_file *m, vo
 
 	if (file) {
 		seq_printf(m, " file=");
-		seq_path(m, file->f_vfsmnt, file->f_dentry, "\n\t");
+		seq_path(m, file->f_vfsmnt, file->f_dentry, "\n\t= ");
 	} else if (vma->vm_start <= mm->brk && vma->vm_end >= mm->start_brk) {
 		seq_printf(m, " heap");
 	} else if (vma->vm_start <= mm->start_stack &&
@@ -1908,8 +1908,8 @@ int show_numa_map(struct seq_file *m, vo
 	if (md->active < md->pages && !is_vm_hugetlb_page(vma))
 		seq_printf(m," active=%lu", md->active);
 
-	if (md->locked)
-		seq_printf(m," locked=%lu", md->locked);
+	if (md->writeback)
+		seq_printf(m," writeback=%lu", md->writeback);
 
 	for_each_online_node(n)
 		if (md->node[n])

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

Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

Andi, Christoph,

In the implementation of migrate_pages() one finds the following 
lines:

err = do_migrate_pages(mm, &old, &new, 
        capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);

while in the implemantation of mbind() we have:

if ((flags & MPOL_MF_MOVE_ALL( && !capable(CAP_SYS_RESOURCE))
        return -EPERM;

Is it really intended to associate two *different* capabilities 
with the operation of MPOL_MF_MOVE_ALL in this fashion?  At
first glance, it seems rather inconsistent to do so.

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Christoph Lameter]

On Wed, 15 Mar 2006, Michael Kerrisk wrote:

> err = do_migrate_pages(mm, &old, &new, 
>         capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
> 
> while in the implemantation of mbind() we have:
> 
> if ((flags & MPOL_MF_MOVE_ALL( && !capable(CAP_SYS_RESOURCE))
>         return -EPERM;
> 
> Is it really intended to associate two *different* capabilities 
> with the operation of MPOL_MF_MOVE_ALL in this fashion?  At
> first glance, it seems rather inconsistent to do so.

You are likely right. Which one is the more correct capability to use?

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

Christoph,

> > err = do_migrate_pages(mm, &old, &new, 
> >         capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
> > 
> > while in the implemantation of mbind() we have:
> > 
> > if ((flags & MPOL_MF_MOVE_ALL( && !capable(CAP_SYS_RESOURCE))
> >         return -EPERM;
> > 
> > Is it really intended to associate two *different* capabilities 
> > with the operation of MPOL_MF_MOVE_ALL in this fashion?  At
> > first glance, it seems rather inconsistent to do so.
> 
> You are likely right. Which one is the more correct capability to use?

Umm -- maybe CAP_SYS_NICE!

Whichever it is, I think it should be consistent.  See below
for why I mention CAP_SYS_NICE.

In case it helps you decide which to use, here's a list of 
what I know each of these capabilities already allows:

CAP_SYS_NICE
Raise process nice value (nice(), setpriority()); 
change nice value for arbitrary processes (setpriority()); 
set SCHED_RR and SCHED_FIFO real-time scheduling policies for 
calling process, set scheduling policies and priorities 
for arbitrary processes (sched_setscheduler(), sched_setparam()); 
set CPU affinity for arbitrary processes (sched_setaffinity())

It seems to me that setting scheduling policy and 
priorities is also the kind of thing that might be performed 
in apps that also use the NUMA API, so it would seem consistent 
to use CAP_SYS_NICE for NUMA also.

CAP_SYS_RESOURCE
Use reserved space on file systems; 
make ioctl() calls controlling ext3 journaling; 
override disk quota limits; 
increase hard resource limits (setrlimit()); 
override RLIMIT_NPROC resource limit (fork()); 
raise msg_qbytes limit for a message queue above limit in 
/proc/sys/kernel/msgmnb; 
bypass various POSIX message queue limits defined by files under 
/proc/sys/fs/mqueue


CAP_SYS_ADMIN
Allow system calls that open files to exceed /proc/sys/fs/file-max 
limit; 
perform various system administration operations including: 
quotactl() (control disk quotas), mount() and umount(), 
swapon() and swapoff(), pivot_root(), sethostname() and setdomainname(); 
override RLIMIT_NPROC resource limit; 
set trusted and security extended attributes; 
perform IPC_SET and IPC_RMID operations on 
arbitrary System V IPC objects; 
forge PID when passing credentials via Unix domain socket;
employ TIOCCONS ioctl() 

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Christoph Lameter]

On Wed, 15 Mar 2006, Michael Kerrisk wrote:

> It seems to me that setting scheduling policy and 
> priorities is also the kind of thing that might be performed 
> in apps that also use the NUMA API, so it would seem consistent 
> to use CAP_SYS_NICE for NUMA also.

Use CAP_SYS_NICE for controlling migration permissions.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.16-rc6/mm/mempolicy.c
===================================================================
--- linux-2.6.16-rc6.orig/mm/mempolicy.c	2006-03-11 14:12:55.000000000 -0800
+++ linux-2.6.16-rc6/mm/mempolicy.c	2006-03-14 16:31:15.000000000 -0800
@@ -748,7 +748,7 @@ long do_mbind(unsigned long start, unsig
 				      MPOL_MF_MOVE | MPOL_MF_MOVE_ALL))
 	    || mode > MPOL_MAX)
 		return -EINVAL;
-	if ((flags & MPOL_MF_MOVE_ALL) && !capable(CAP_SYS_RESOURCE))
+	if ((flags & MPOL_MF_MOVE_ALL) && !capable(CAP_SYS_NICE))
 		return -EPERM;
 
 	if (start & ~PAGE_MASK)
@@ -942,20 +942,20 @@ asmlinkage long sys_migrate_pages(pid_t 
 	 */
 	if ((current->euid != task->suid) && (current->euid != task->uid) &&
 	    (current->uid != task->suid) && (current->uid != task->uid) &&
-	    !capable(CAP_SYS_ADMIN)) {
+	    !capable(CAP_SYS_NICE)) {
 		err = -EPERM;
 		goto out;
 	}
 
 	task_nodes = cpuset_mems_allowed(task);
 	/* Is the user allowed to access the target nodes? */
-	if (!nodes_subset(new, task_nodes) && !capable(CAP_SYS_ADMIN)) {
+	if (!nodes_subset(new, task_nodes) && !capable(CAP_SYS_NICE)) {
 		err = -EPERM;
 		goto out;
 	}
 
 	err = do_migrate_pages(mm, &old, &new,
-		capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
+		capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
 out:
 	mmput(mm);
 	return err;

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

> --- Ursprungliche Nachricht ---
> Von: Christoph Lameter <clameter@sgi.com>
> An: akpm@osdl.org
> Kopie: Michael Kerrisk <mtk-manpages@gmx.net>, ak@suse.de,
> linux-mm@kvack.org, michael.kerrisk@gmx.net
> Betreff: Re: Inconsistent capabilites associated with MPOL_MOVE_ALL
> Datum: Tue, 14 Mar 2006 16:33:29 -0800 (PST)
> 
> On Wed, 15 Mar 2006, Michael Kerrisk wrote:
> 
> > It seems to me that setting scheduling policy and 
> > priorities is also the kind of thing that might be performed 
> > in apps that also use the NUMA API, so it would seem consistent 
> > to use CAP_SYS_NICE for NUMA also.
> 
> Use CAP_SYS_NICE for controlling migration permissions.

Ahhh -- the sweet smell of consistency...

Thanks!

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Andrew Morton]

Christoph Lameter <clameter@sgi.com> wrote:
>
> Use CAP_SYS_NICE for controlling migration permissions.
>

ahem.  Kind of eleventh-hour.  Are we really sure?

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Christoph Lameter]

On Tue, 14 Mar 2006, Andrew Morton wrote:

> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > Use CAP_SYS_NICE for controlling migration permissions.
> ahem.  Kind of eleventh-hour.  Are we really sure?

This may still get into 2.6.16??? Then I'd also like to have 
the documentation update in and the fix for the retries on VM_LOCKED. The 
VM_LOCKED patch changes the migration API for filesystems and I really 
would like to limit the changes after 2.6.16 is out.

Michael had the first intelligent comment on the use of the 
capabilities in page migration that I have seen and he actually made 
more sense than my reasoning.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

> Von: Andrew Morton <akpm@osdl.org>
> 
> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > Use CAP_SYS_NICE for controlling migration permissions.
> >
> 
> ahem.  Kind of eleventh-hour.  Are we really sure?

Hi Andrew,

I see that Christoph already commented, but just to aff.
Not sure if you are on linux-mm.  In case not, the message 
below provides some context that might help.

Cheers,

Michael

--- Weitergeleitete Nachricht ---
Von: "Michael Kerrisk" <mtk-manpages@gmx.net>
An: Christoph Lameter <clameter@sgi.com>
Kopie: ak@suse.de, linux-mm@kvack.org, michael.kerrisk@gmx.net
Betreff: Re: Inconsistent capabilites associated with MPOL_MOVE_ALL
Datum: Wed, 15 Mar 2006 01:25:27 +0100 (MET)

Christoph,

> > err = do_migrate_pages(mm, &old, &new, 
> >         capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
> > 
> > while in the implemantation of mbind() we have:
> > 
> > if ((flags & MPOL_MF_MOVE_ALL( && !capable(CAP_SYS_RESOURCE))
> >         return -EPERM;
> > 
> > Is it really intended to associate two *different* capabilities 
> > with the operation of MPOL_MF_MOVE_ALL in this fashion?  At
> > first glance, it seems rather inconsistent to do so.
> 
> You are likely right. Which one is the more correct capability to use?

Umm -- maybe CAP_SYS_NICE!

Whichever it is, I think it should be consistent.  See below
for why I mention CAP_SYS_NICE.

In case it helps you decide which to use, here's a list of 
what I know each of these capabilities already allows:

CAP_SYS_NICE
Raise process nice value (nice(), setpriority()); 
change nice value for arbitrary processes (setpriority()); 
set SCHED_RR and SCHED_FIFO real-time scheduling policies for 
calling process, set scheduling policies and priorities 
for arbitrary processes (sched_setscheduler(), sched_setparam()); 
set CPU affinity for arbitrary processes (sched_setaffinity())

It seems to me that setting scheduling policy and 
priorities is also the kind of thing that might be performed 
in apps that also use the NUMA API, so it would seem consistent 
to use CAP_SYS_NICE for NUMA also.

CAP_SYS_RESOURCE
Use reserved space on file systems; 
make ioctl() calls controlling ext3 journaling; 
override disk quota limits; 
increase hard resource limits (setrlimit()); 
override RLIMIT_NPROC resource limit (fork()); 
raise msg_qbytes limit for a message queue above limit in 
/proc/sys/kernel/msgmnb; 
bypass various POSIX message queue limits defined by files under 
/proc/sys/fs/mqueue


CAP_SYS_ADMIN
Allow system calls that open files to exceed /proc/sys/fs/file-max 
limit; 
perform various system administration operations including: 
quotactl() (control disk quotas), mount() and umount(), 
swapon() and swapoff(), pivot_root(), sethostname() and setdomainname(); 
override RLIMIT_NPROC resource limit; 
set trusted and security extended attributes; 
perform IPC_SET and IPC_RMID operations on 
arbitrary System V IPC objects; 
forge PID when passing credentials via Unix domain socket;
employ TIOCCONS ioctl() 

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Andrew Morton]

Christoph Lameter <clameter@sgi.com> wrote:
>
> On Tue, 14 Mar 2006, Andrew Morton wrote:
> 
> > Christoph Lameter <clameter@sgi.com> wrote:
> > >
> > > Use CAP_SYS_NICE for controlling migration permissions.
> > ahem.  Kind of eleventh-hour.  Are we really sure?
> 
> This may still get into 2.6.16???

Well it changes the userspace API.

> Then I'd also like to have 
> the documentation update in and the fix for the retries on VM_LOCKED.

gargh, pelase don't send me off to read hundreds of patches to work out
which one you're referring to :(

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

> Von: Andrew Morton <akpm@osdl.org>
> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > On Tue, 14 Mar 2006, Andrew Morton wrote:
> > 
> > > Christoph Lameter <clameter@sgi.com> wrote:
> > > >
> > > > Use CAP_SYS_NICE for controlling migration permissions.
> > > ahem.  Kind of eleventh-hour.  Are we really sure?
> > 
> > This may still get into 2.6.16???
> 
> Well it changes the userspace API.

No -- both of these changes affect interfaces
that are only part of the unreleased 2.6.16. 
(MPOL_MF_MOVE_ALL is new in 2.6.16.)

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Christoph Lameter]

On Tue, 14 Mar 2006, Andrew Morton wrote:

> > This may still get into 2.6.16???
> 
> Well it changes the userspace API.

I am still working on the tool so its fine now.

> > Then I'd also like to have 
> > the documentation update in and the fix for the retries on VM_LOCKED.
> 
> gargh, pelase don't send me off to read hundreds of patches to work out
> which one you're referring to :(

Ok...

page-migration-fail-if-page-is-in-a-vma-flagged-vm_locked.patch
page-migration-documentation-update.patch

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Michael Kerrisk]

> > Von: Andrew Morton <akpm@osdl.org>
> > Christoph Lameter <clameter@sgi.com> wrote:
> > >
> > > On Tue, 14 Mar 2006, Andrew Morton wrote:
> > > 
> > > > Christoph Lameter <clameter@sgi.com> wrote:
> > > > >
> > > > > Use CAP_SYS_NICE for controlling migration permissions.
> > > > ahem.  Kind of eleventh-hour.  Are we really sure?
> > > 
> > > This may still get into 2.6.16???
> > 
> > Well it changes the userspace API.
> 
> No -- both of these changes affect interfaces
> that are only part of the unreleased 2.6.16. 
> (MPOL_MF_MOVE_ALL is new in 2.6.16.)

Replying to self...

Ooops sorry about the last -- I see that Christoph is changing stuff in 
addition to what I was proposing...  (But it makes sense to me, from a 
consistency point of view.)

Cheers,

Michael

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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Christoph Lameter]

On Wed, 15 Mar 2006, Michael Kerrisk wrote:

> Ooops sorry about the last -- I see that Christoph is changing stuff in 
> addition to what I was proposing...  (But it makes sense to me, from a 
> consistency point of view.)

No these are all related to MPOL_MOVE_ALL. Either for mbind() or 
migrate_pages().


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

Re: Inconsistent capabilites associated with MPOL_MOVE_ALL

[Andrew Morton]

"Michael Kerrisk" <mtk-manpages@gmx.net> wrote:
>
>  I see that Christoph already commented, but just to aff.
>  Not sure if you are on linux-mm.  In case not, the message 
>  below provides some context that might help.

<squeaky wheel>That's actually what changelogs are for</squeaky wheel>

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