On 2017-09-04 i??i?? 5:30, Konstantin Khlebnikov wrote:

On 04.09.2017 04:35, Kyeongdon Kim wrote:

quoted

Thanks for your reply,
But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that 

vmstat counter? or others?

quoted

I mean rather than adding bunch vmstat counters for operations it 
might be
worth to add page counter which will show current amount of these pages.
But this seems too low-level for tracking, common counters for all 
network
buffers would be more useful but much harder to implement.

Ok, thanks for the comment.

As I can see page owner is able to save stacktrace where allocation 
happened,
this makes debugging mostly trivial without any counters. If it adds 
too much
overhead - just track random 1% of pages, should be enough for finding 
leak.

As I said, we already used page owner tools to resolve the leak issue.
But that's extremely difficult to figure it out,
too much callstack and too much allocation orders(0 or more).
We couldn't easily get a clue event if we track 1% of pages..

In fact, I was writing another email to send a new patch with debug config.
We added a hash function to pick out address with callstack by using 
debugfs,
It could be showing the only page_frag_cache leak with owner.

for exmaple code :

+++ /mm/page_alloc.c

@@ -4371,7 +4371,9 @@ void *page_frag_alloc(struct page_frag_cache *nc,

 A A A A A A A  nc->pagecnt_bias--;
 A A A A A A A  nc->offset = offset;
+#ifdef CONFIG_PGFRAG_DEBUG
+A A A A A A  page_frag_debug_alloc(nc->va + offset);
+#endif
 A A A A A A A  return nc->va + offset;
 A }
 A EXPORT_SYMBOL(page_frag_alloc);

@@ -4382,7 +4384,9 @@ EXPORT_SYMBOL(page_frag_alloc);
 A void page_frag_free(void *addr)
 A {
 A A A A A A A  struct page *page = virt_to_head_page(addr);
+#ifdef CONFIG_PGFRAG_DEBUG
+A A A A A A  page_frag_debug_free(addr);
+#endif
 A A A A A A A  if (unlikely(put_page_testzero(page)))

Those counters that I added may be too much for the linux server or 
something.
However, I think the other systems may need to simple debugging method.
(like Android OS)

So if you can accept the patch with debug feature,
I will send it including counters.
but still thinking those counters don't need. I won't.

Anyway, I'm grateful for your feedback, means a lot to me.

Thanks,
Kyeongdon Kim

quoted

As you know, page_frag_alloc() directly calls 

__alloc_pages_nodemask() function,

quoted

so that makes too difficult to see memory usage in real time even 

though we have "/meminfo or /slabinfo.." information.

quoted

If there was a way already to figure out the memory leakage from 

page_frag_cache in mainline, I agree your opinion

quoted

but I think we don't have it now.

If those counters too much in my patch,
I can say two values (pgfrag_alloc and pgfrag_free) are enough to 

guess what will happen

quoted

and would remove pgfrag_alloc_calls and pgfrag_free_calls.

Thanks,
Kyeongdon Kim

quoted

quoted

IMHO that's too much counters.
Per-node NR_FRAGMENT_PAGES should be enough for guessing what's 

going on.

quoted

quoted

Perf probes provides enough features for furhter debugging.

On 01.09.2017 02:37, Kyeongdon Kim wrote:

quoted

There was a memory leak problem when we did stressful test
on Android device.
The root cause of this was from page_frag_cache alloc
and it was very hard to find out.

We add to count the page frag allocation and free with function 

call.

quoted

quoted

quoted

The gap between pgfrag_alloc and pgfrag_free is good to to calculate
for the amount of page.
The gap between pgfrag_alloc_calls and pgfrag_free_calls is for
sub-indicator.
They can see trends of memory usage during the test.
Without it, it's difficult to check page frag usage so I believe we
should add it.

Signed-off-by: Kyeongdon Kim <redacted>
---

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