From: Vaneet Narang <v.narang@samsung.com>
To: Dmitry Vyukov <dvyukov@google.com>, Michal Hocko <mhocko@kernel.org>
Cc: Maninder Singh <maninder1.s@samsung.com>,
"kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"jkosina@suse.cz" <jkosina@suse.cz>,
"pombredanne@nexb.com" <pombredanne@nexb.com>,
"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"guptap@codeaurora.org" <guptap@codeaurora.org>,
"vinmenon@codeaurora.org" <vinmenon@codeaurora.org>,
AMIT SAHRAWAT <a.sahrawat@samsung.com>,
PANKAJ MISHRA <pankaj.m@samsung.com>,
Lalit Mohan Tripathi <lalit.mohan@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
kasan-dev <kasan-dev@googlegroups.com>
Subject: RE: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.
Date: Fri, 24 Nov 2017 11:57:07 +0000 [thread overview]
Message-ID: <20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701@epcms5p4> (raw)
In-Reply-To: <CACT4Y+bF7TGFS+395kyzdw21M==ECgs+dCjV0e3Whkvm1_piDA@mail.gmail.com>
Hi Michal,
>> 5) To check number of entries in stackdepot to decide stackdepot hash size for different systems.
>> For fewer entries hash table size can be reduced from 4MB.
>
> What are you going to do with that information. It is not like you can
> reduce the memory footprint or somehow optimize anything during the
> runtime.
On low memory system where page owner entries are in range of 3k ~ 4k, its
a waste to keep hash table size of 4MB. It can be modified to some 128KB to
save memory footprint of stackdepot. So stackdepot entry count is important.
> OK, so debugging a debugging facility... I do not think we want to
> introduce a lot of code for something like that.
We enabled stackdepot on our system and realised, in long run stack depot consumes
more runtime memory then it actually needs. we used shared patch to debug this issue.
stack stores following two unique entries. Page allocation done in interrupt
context will generate a unique stack trace. Consider following two entries.
Entry 1:
__alloc_pages_nodemask+0xec/0x200
page_frag_alloc+0x84/0x140
__napi_alloc_skb+0x83/0xe0
rtl8169_poll+0x1e5/0x670
net_rx_action+0x122/0x380
__do_softirq+0xce/0x298
irq_exit+0xa3/0xb0
-------------------
do_IRQ+0x72/0xc0
ret_from_intr+0x0/0x14
rw_copy_check_uvector+0x8a/0x100
import_iovec+0x27/0xc0
copy_msghdr_from_user+0xc0/0x120
___sys_recvmsg+0x76/0x210
__sys_recvmsg+0x39/0x70
entry_SYSCALL_64_fastpath+0x13/
Entry 2:
__alloc_pages_nodemask+0xec/0x200
page_frag_alloc+0x84/0x140
__napi_alloc_skb+0x83/0xe0
rtl8169_poll+0x1e5/0x670
net_rx_action+0x122/0x380
__do_softirq+0xce/0x298
irq_exit+0xa3/0xb0
-------------------
smp_apic_timer_interrupt+0x5b/0x110
apic_timer_interrupt+0x89/0x90
cpuidle_enter_state+0x95/0x2c0
do_idle+0x163/0x1a0
cpu_startup_entry+0x14/0x20
secondary_startup_64+0xa5/0xb0
Actual Allocation Path is
__alloc_pages_nodemask+0xec/0x200
page_frag_alloc+0x84/0x140
__napi_alloc_skb+0x83/0xe0
rtl8169_poll+0x1e5/0x670
net_rx_action+0x122/0x380
__do_softirq+0xce/0x298
irq_exit+0xa3/0xb0
We have been getting similar kind of such entries and eventually
stackdepot reaches Max Cap. So we found this interface useful in debugging
stackdepot issue so shared in community.
Regards,
Vaneet Narang
--
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>
next prev parent reply other threads:[~2017-11-24 12:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcas5p1.samsung.com>
2017-11-22 10:47 ` Maninder Singh
2017-11-23 16:28 ` Michal Hocko
[not found] ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p3>
2017-11-24 9:41 ` Maninder Singh
2017-11-24 9:54 ` Michal Hocko
2017-11-24 10:23 ` Dmitry Vyukov
[not found] ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p4>
2017-11-24 11:57 ` Vaneet Narang [this message]
2017-11-24 12:44 ` Michal Hocko
[not found] ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p7>
2017-11-24 13:30 ` Vaneet Narang
2017-11-24 13:48 ` Michal Hocko
2017-11-28 3:37 ` Vinayak Menon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701@epcms5p4 \
--to=v.narang@samsung.com \
--cc=a.sahrawat@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guptap@codeaurora.org \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=kasan-dev@googlegroups.com \
--cc=kstewart@linuxfoundation.org \
--cc=lalit.mohan@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maninder1.s@samsung.com \
--cc=mhocko@kernel.org \
--cc=pankaj.m@samsung.com \
--cc=pombredanne@nexb.com \
--cc=vbabka@suse.cz \
--cc=vinmenon@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox