On 11/24/2017 7:00 PM, Vaneet Narang wrote:
> Hi Michal,
>
>>> 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.
>
>> Then use it for internal debugging and provide a code which would scale
>> better on smaller systems. We do not need this in the kernel IMHO. We do
>> not merge all the debugging patches we use for internal development.
> `
> Not just debugging but this information can also be used to profile and tune stack depot.
> Getting count of stack entries would help in deciding hash table size and
> page order used by stackdepot.
>
> For less entries, bigger hash table and higher page order slabs might not be required as
> maintained by stackdepot. As i already mentioned smaller size hashtable can be choosen and
> similarly lower order pages can be used for slabs.
>
> If you think its useful, we can share scalable patch to configure below two values based on
> number of stack entries dynamically.
>
> #define STACK_ALLOC_ORDER 2
> #define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
It will be good if this hash table size can be tuned somehow. When CONFIG_PAGE_OWNER is enabled, we expect it to
consume significant amount of memory only when "page_owner" kernel param is set. But since PAGE_OWNER selects
STACKDEPOT, it consumes around 8MB (stack_table) on 64 bit without even a single stack being stored. This is a problem
on low RAM targets where we want to keep CONFIG_PAGE_OWNER enabled by default and for debugging enable the
feature via the kernel param.
I am not sure how feasible it is to configure it dynamically, but I think a hash_size early param and then a memblock alloc
of stack table at boot would work and help low ram devices.
Thanks,
Vinayak
From 1584955497770827380@xxx Fri Nov 24 13:49:10 +0000 2017
X-GM-THRID: 1584763196629983480
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Fri 24-11-17 11:57:07, Vaneet Narang wrote:
[...]
> > 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.
[...]
> 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.
Then use it for internal debugging and provide a code which would scale
better on smaller systems. We do not need this in the kernel IMHO. We do
not merge all the debugging patches we use for internal development.
--
Michal Hocko
SUSE Labs
From 1584950840089968403@xxx Fri Nov 24 12:35:08 +0000 2017
X-GM-THRID: 1584763196629983480
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
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
From 1584942702254884291@xxx Fri Nov 24 10:25:48 +0000 2017
X-GM-THRID: 1584763196629983480
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread