[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701@epcms5p4>
Date: Fri, 24 Nov 2017 11:57:07 +0000
From: Vaneet Narang <v.narang@...sung.com>
To: Dmitry Vyukov <dvyukov@...gle.com>,
Michal Hocko <mhocko@...nel.org>
CC: Maninder Singh <maninder1.s@...sung.com>,
"kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jkosina@...e.cz" <jkosina@...e.cz>,
"pombredanne@...b.com" <pombredanne@...b.com>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"guptap@...eaurora.org" <guptap@...eaurora.org>,
"vinmenon@...eaurora.org" <vinmenon@...eaurora.org>,
AMIT SAHRAWAT <a.sahrawat@...sung.com>,
PANKAJ MISHRA <pankaj.m@...sung.com>,
Lalit Mohan Tripathi <lalit.mohan@...sung.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: RE: Re: [PATCH 1/1] stackdepot: interface to check entries and size
of stackdepot.
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
Powered by blists - more mailing lists