[PATCH 1/3] proc: add /proc/kpageorder interface

[PATCH 1/3] proc: add /proc/kpageorder interface

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: [PATCH] proc: add /proc/kpageorder interface

This makes page order information available to the user-space.

Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 fs/proc/page.c              |   48 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mm.h          |   11 ++++++++++
 kernel/events/internal.h    |    8 +++----
 kernel/events/ring_buffer.c |   10 ++++-----
 mm/internal.h               |   11 ----------
 5 files changed, 68 insertions(+), 20 deletions(-)

Index: b/fs/proc/page.c
===================================================================
--- a/fs/proc/page.c	2012-05-31 16:24:12.323109710 +0200
+++ b/fs/proc/page.c	2012-05-31 16:33:35.819109657 +0200
@@ -207,10 +207,58 @@ static const struct file_operations proc
 	.read = kpageflags_read,
 };
 
+static ssize_t kpageorder_read(struct file *file, char __user *buf,
+			     size_t count, loff_t *ppos)
+{
+	u64 __user *out = (u64 __user *)buf;
+	struct page *ppage;
+	unsigned long src = *ppos;
+	unsigned long pfn;
+	ssize_t ret = 0;
+	u64 porder;
+
+	pfn = src / KPMSIZE;
+	count = min_t(unsigned long, count,
+		      ((ARCH_PFN_OFFSET + max_pfn) * KPMSIZE) - src);
+	if (src & KPMMASK || count & KPMMASK)
+		return -EINVAL;
+
+	while (count > 0) {
+		if (pfn_valid(pfn))
+			ppage = pfn_to_page(pfn);
+		else
+			ppage = NULL;
+		if (!ppage || !PageBuddy(ppage))
+			porder = 0;
+		else
+			porder = page_order(ppage);
+
+		if (put_user(porder, out)) {
+			ret = -EFAULT;
+			break;
+		}
+
+		pfn++;
+		out++;
+		count -= KPMSIZE;
+	}
+
+	*ppos += (char __user *)out - buf;
+	if (!ret)
+		ret = (char __user *)out - buf;
+	return ret;
+}
+
+static const struct file_operations proc_kpageorder_operations = {
+	.llseek = mem_lseek,
+	.read = kpageorder_read,
+};
+
 static int __init proc_page_init(void)
 {
 	proc_create("kpagecount", S_IRUSR, NULL, &proc_kpagecount_operations);
 	proc_create("kpageflags", S_IRUSR, NULL, &proc_kpageflags_operations);
+	proc_create("kpageorder", S_IRUSR, NULL, &proc_kpageorder_operations);
 	return 0;
 }
 module_init(proc_page_init);
Index: b/include/linux/mm.h
===================================================================
--- a/include/linux/mm.h	2012-05-31 16:24:12.295109717 +0200
+++ b/include/linux/mm.h	2012-05-31 16:30:49.215109568 +0200
@@ -250,6 +250,17 @@ struct inode;
 #define set_page_private(page, v)	((page)->private = (v))
 
 /*
+ * function for dealing with page's order in buddy system.
+ * zone->lock is already acquired when we use these.
+ * So, we don't need atomic page->flags operations here.
+ */
+static inline unsigned long page_order(struct page *page)
+{
+	/* PageBuddy() must be checked by the caller */
+	return page_private(page);
+}
+
+/*
  * FIXME: take this include out, include page-flags.h in
  * files which need it (119 of them)
  */
Index: b/kernel/events/internal.h
===================================================================
--- a/kernel/events/internal.h	2012-05-31 16:24:12.307109719 +0200
+++ b/kernel/events/internal.h	2012-05-31 16:30:49.215109568 +0200
@@ -58,14 +58,14 @@ perf_mmap_to_page(struct ring_buffer *rb
  * Required for architectures that have d-cache aliasing issues.
  */
 
-static inline int page_order(struct ring_buffer *rb)
+static inline int rb_page_order(struct ring_buffer *rb)
 {
 	return rb->page_order;
 }
 
 #else
 
-static inline int page_order(struct ring_buffer *rb)
+static inline int rb_page_order(struct ring_buffer *rb)
 {
 	return 0;
 }
@@ -73,7 +73,7 @@ static inline int page_order(struct ring
 
 static inline unsigned long perf_data_size(struct ring_buffer *rb)
 {
-	return rb->nr_pages << (PAGE_SHIFT + page_order(rb));
+	return rb->nr_pages << (PAGE_SHIFT + rb_page_order(rb));
 }
 
 static inline void
@@ -95,7 +95,7 @@ __output_copy(struct perf_output_handle 
 			handle->page++;
 			handle->page &= rb->nr_pages - 1;
 			handle->addr = rb->data_pages[handle->page];
-			handle->size = PAGE_SIZE << page_order(rb);
+			handle->size = PAGE_SIZE << rb_page_order(rb);
 		}
 	} while (len);
 }
Index: b/kernel/events/ring_buffer.c
===================================================================
--- a/kernel/events/ring_buffer.c	2012-05-31 16:24:12.315109715 +0200
+++ b/kernel/events/ring_buffer.c	2012-05-31 16:30:49.215109568 +0200
@@ -154,12 +154,12 @@ int perf_output_begin(struct perf_output
 	if (head - local_read(&rb->wakeup) > rb->watermark)
 		local_add(rb->watermark, &rb->wakeup);
 
-	handle->page = offset >> (PAGE_SHIFT + page_order(rb));
+	handle->page = offset >> (PAGE_SHIFT + rb_page_order(rb));
 	handle->page &= rb->nr_pages - 1;
-	handle->size = offset & ((PAGE_SIZE << page_order(rb)) - 1);
+	handle->size = offset & ((PAGE_SIZE << rb_page_order(rb)) - 1);
 	handle->addr = rb->data_pages[handle->page];
 	handle->addr += handle->size;
-	handle->size = (PAGE_SIZE << page_order(rb)) - handle->size;
+	handle->size = (PAGE_SIZE << rb_page_order(rb)) - handle->size;
 
 	if (have_lost) {
 		lost_event.header.type = PERF_RECORD_LOST;
@@ -310,7 +310,7 @@ void rb_free(struct ring_buffer *rb)
 struct page *
 perf_mmap_to_page(struct ring_buffer *rb, unsigned long pgoff)
 {
-	if (pgoff > (1UL << page_order(rb)))
+	if (pgoff > (1UL << rb_page_order(rb)))
 		return NULL;
 
 	return vmalloc_to_page((void *)rb->user_page + pgoff * PAGE_SIZE);
@@ -330,7 +330,7 @@ static void rb_free_work(struct work_str
 	int i, nr;
 
 	rb = container_of(work, struct ring_buffer, work);
-	nr = 1 << page_order(rb);
+	nr = 1 << rb_page_order(rb);
 
 	base = rb->user_page;
 	for (i = 0; i < nr + 1; i++)
Index: b/mm/internal.h
===================================================================
--- a/mm/internal.h	2012-05-31 16:24:12.299109722 +0200
+++ b/mm/internal.h	2012-05-31 16:30:49.215109568 +0200
@@ -141,17 +141,6 @@ isolate_migratepages_range(struct zone *
 
 #endif
 
-/*
- * function for dealing with page's order in buddy system.
- * zone->lock is already acquired when we use these.
- * So, we don't need atomic page->flags operations here.
- */
-static inline unsigned long page_order(struct page *page)
-{
-	/* PageBuddy() must be checked by the caller */
-	return page_private(page);
-}
-
 /* mm/util.c */
 void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
 		struct vm_area_struct *prev, struct rb_node *rb_parent);

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] proc: add /proc/kpageorder interface

[KOSAKI Motohiro]

(6/1/12 12:54 PM), Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz<b.zolnierkie@samsung.com>
> Subject: [PATCH] proc: add /proc/kpageorder interface
>
> This makes page order information available to the user-space.

No usecase new feature always should be NAKed.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] proc: add /proc/kpageorder interface

[Bartlomiej Zolnierkiewicz]

On Friday 01 June 2012 22:31:01 KOSAKI Motohiro wrote:
> (6/1/12 12:54 PM), Bartlomiej Zolnierkiewicz wrote:
> > From: Bartlomiej Zolnierkiewicz<b.zolnierkie@samsung.com>
> > Subject: [PATCH] proc: add /proc/kpageorder interface
> >
> > This makes page order information available to the user-space.
> 
> No usecase new feature always should be NAKed.

It is used to get page orders for Buddy pages and help to monitor
free/used pages.  Sample usage will be posted for inclusion to
Pagemap Demo tools (http://selenic.com/repo/pagemap/).

The similar situation is with /proc/kpagetype..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung Poland R&D Center

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] proc: add /proc/kpageorder interface

[KOSAKI Motohiro]

(6/4/12 4:23 AM), Bartlomiej Zolnierkiewicz wrote:
> On Friday 01 June 2012 22:31:01 KOSAKI Motohiro wrote:
>> (6/1/12 12:54 PM), Bartlomiej Zolnierkiewicz wrote:
>>> From: Bartlomiej Zolnierkiewicz<b.zolnierkie@samsung.com>
>>> Subject: [PATCH] proc: add /proc/kpageorder interface
>>>
>>> This makes page order information available to the user-space.
>>
>> No usecase new feature always should be NAKed.
>
> It is used to get page orders for Buddy pages and help to monitor
> free/used pages.  Sample usage will be posted for inclusion to
> Pagemap Demo tools (http://selenic.com/repo/pagemap/).
>
> The similar situation is with /proc/kpagetype..

NAK then.

First, your explanation didn't describe any usecase. "There is a similar feature"
is NOT a usecase.

Second, /proc/kpagetype is one of mistaken feature. It was not designed deeply.
We have no reason to follow the mistake.

Third, pagemap demo doesn't describe YOUR feature's usefull at all.

Fourth, pagemap demo is NOT useful at all. It's just toy. Practically, kpagetype
is only used from pagetype tool.

Firnally, you have to learn what "usecase" mean.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] proc: add /proc/kpageorder interface

[Bartlomiej Zolnierkiewicz]

On Monday 04 June 2012 21:31:25 KOSAKI Motohiro wrote:
> (6/4/12 4:23 AM), Bartlomiej Zolnierkiewicz wrote:
> > On Friday 01 June 2012 22:31:01 KOSAKI Motohiro wrote:
> >> (6/1/12 12:54 PM), Bartlomiej Zolnierkiewicz wrote:
> >>> From: Bartlomiej Zolnierkiewicz<b.zolnierkie@samsung.com>
> >>> Subject: [PATCH] proc: add /proc/kpageorder interface
> >>>
> >>> This makes page order information available to the user-space.
> >>
> >> No usecase new feature always should be NAKed.
> >
> > It is used to get page orders for Buddy pages and help to monitor
> > free/used pages.  Sample usage will be posted for inclusion to
> > Pagemap Demo tools (http://selenic.com/repo/pagemap/).
> >
> > The similar situation is with /proc/kpagetype..
> 
> NAK then.
> 
> First, your explanation didn't describe any usecase. "There is a similar feature"
> is NOT a usecase.
> 
> Second, /proc/kpagetype is one of mistaken feature. It was not designed deeply.
> We have no reason to follow the mistake.

Well, my usecase for /proc/kpagetype is to monitor/debug pageblock changes
(i.e. to verify CMA and compaction operations).  It is not perfect since
interface gives us only a snapshot of pageblocks state at some random time.
However it is a straightforward method and requires only minimal changes
to the existing code.

Maybe there is a better way to do this which would give a more accurate
data and capture every state change (maybe a one involving tracing?) but
I don't know about it.  Do you know such better way to do it?

> Third, pagemap demo doesn't describe YOUR feature's usefull at all.

pagemap demo doesn't include my patches for /proc/kpage[order,type] yet
so it is not surprising at all (it doesn't even work with current kernels
without my other patches).. ;)

> Fourth, pagemap demo is NOT useful at all. It's just toy. Practically, kpagetype
> is only used from pagetype tool.

I don't quite follow it, what pagetype tool are you referring to (kpagetype
is a new interface)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung Poland R&D Center

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] proc: add /proc/kpageorder interface

[KOSAKI Motohiro]

(6/6/12 4:23 AM), Bartlomiej Zolnierkiewicz wrote:
> On Monday 04 June 2012 21:31:25 KOSAKI Motohiro wrote:
>> (6/4/12 4:23 AM), Bartlomiej Zolnierkiewicz wrote:
>>> On Friday 01 June 2012 22:31:01 KOSAKI Motohiro wrote:
>>>> (6/1/12 12:54 PM), Bartlomiej Zolnierkiewicz wrote:
>>>>> From: Bartlomiej Zolnierkiewicz<b.zolnierkie@samsung.com>
>>>>> Subject: [PATCH] proc: add /proc/kpageorder interface
>>>>>
>>>>> This makes page order information available to the user-space.
>>>>
>>>> No usecase new feature always should be NAKed.
>>>
>>> It is used to get page orders for Buddy pages and help to monitor
>>> free/used pages.  Sample usage will be posted for inclusion to
>>> Pagemap Demo tools (http://selenic.com/repo/pagemap/).
>>>
>>> The similar situation is with /proc/kpagetype..
>>
>> NAK then.
>>
>> First, your explanation didn't describe any usecase. "There is a similar feature"
>> is NOT a usecase.
>>
>> Second, /proc/kpagetype is one of mistaken feature. It was not designed deeply.
>> We have no reason to follow the mistake.
>
> Well, my usecase for /proc/kpagetype is to monitor/debug pageblock changes
> (i.e. to verify CMA and compaction operations).  It is not perfect since
> interface gives us only a snapshot of pageblocks state at some random time.
> However it is a straightforward method and requires only minimal changes
> to the existing code.
>
> Maybe there is a better way to do this which would give a more accurate
> data and capture every state change (maybe a one involving tracing?) but
> I don't know about it.  Do you know such better way to do it?

To export bare data structure and to export statistics are completely different.
When you need statistics, you should implement to mere stat. Data structure exporting
have significant two dawonsides. 1) they are often bring us security issue and 2)
they easily become a source of kernel enhancement blocker. because we can't break ABIs
forever.


>> Third, pagemap demo doesn't describe YOUR feature's usefull at all.
>
> pagemap demo doesn't include my patches for /proc/kpage[order,type] yet
> so it is not surprising at all (it doesn't even work with current kernels
> without my other patches).. ;)
>
>> Fourth, pagemap demo is NOT useful at all. It's just toy. Practically, kpagetype
>> is only used from pagetype tool.
>
> I don't quite follow it, what pagetype tool are you referring to (kpagetype
> is a new interface)?

pagetype show a _stastics_. then nobody uses pfn internal structure.



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