On 2017-09-04 오후 5:30, Konstantin Khlebnikov wrote:
On 04.09.2017 04:35, Kyeongdon Kim wrote:
> Thanks for your reply,
> But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that
vmstat counter? or others?
>
I mean rather than adding bunch vmstat counters for operations it
might be
On 04.09.2017 04:35, Kyeongdon Kim wrote:
Thanks for your reply,
But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that vmstat
counter? or others?
I mean rather than adding bunch vmstat counters for operations it might be
worth to add page counter which will show current amount
Thanks for your reply,
We already used other i/f like page_owner and kmemleak to resolve memory
leakage issue.
But, page_owner can only for guess but cannot find intuitively memory
usage regarding page_frag_cache.
And kmemleak cannot use (because of calling directly
__alloc_pages_nodemask()).
Thanks for your reply,
But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that
vmstat counter? or others?
As you know, page_frag_alloc() directly calls __alloc_pages_nodemask()
function,
so that makes too difficult to see memory usage in real time even though
we have "/meminfo or
On Fri 01-09-17 12:12:36, Konstantin Khlebnikov wrote:
> IMHO that's too much counters.
> Per-node NR_FRAGMENT_PAGES should be enough for guessing what's going on.
> Perf probes provides enough features for furhter debugging.
I would tend to agree. Adding a counter based on a single debugging
inst
IMHO that's too much counters.
Per-node NR_FRAGMENT_PAGES should be enough for guessing what's going on.
Perf probes provides enough features for furhter debugging.
On 01.09.2017 02:37, Kyeongdon Kim wrote:
There was a memory leak problem when we did stressful test
on Android device.
The root ca
6 matches
Mail list logo
