Messages in this thread | | | Date | Tue, 08 Sep 2015 15:44:28 +0900 | From | AKASHI Takahiro <> | Subject | Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts. |
| |
On 09/08/2015 10:45 AM, AKASHI Takahiro wrote: > Jungseok, > > On 09/08/2015 01:34 AM, Jungseok Lee wrote: >> On Sep 8, 2015, at 1:06 AM, James Morse wrote: >>> On 07/09/15 16:48, Jungseok Lee wrote: >>>> On Sep 7, 2015, at 11:36 PM, James Morse wrote: >>>> >>>> Hi James, >>>> >>>>> Having to handle interrupts on top of an existing kernel stack means the >>>>> kernel stack must be large enough to accomodate both the maximum kernel >>>>> usage, and the maximum irq handler usage. Switching to a different stack >>>>> when processing irqs allows us to make the stack size smaller. >>>>> >>>>> Maximum kernel stack usage (running ltp and generating usb+ethernet >>>>> interrupts) was 7256 bytes. With this patch, the same workload gives >>>>> a maximum stack usage of 5816 bytes. >>>> >>>> I'd like to know how to measure the max stack depth. >>>> AFAIK, a stack tracer on ftrace does not work well. Did you dump a stack >>>> region and find or track down an untouched region? >>> >>> I enabled the 'Trace max stack' option under menuconfig 'Kernel Hacking' -> >>> 'Tracers', then looked in debugfs:/tracing/stack_max_size. >>> >>> What problems did you encounter? >>> (I may be missing something…) >> >> When I enabled the feature, all entries had *0* size except the last entry. >> It can be reproduced easily as looking in debugs:/tracing/stack_trace. > > I'm afraid that you have not applied one of patches in my RFC: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355919.html > > I have not looked into James' patch in details, but hope that it will help > fix one of issues that are annoying me: Stack tracer (actually save_stack_trace()) > will miss a function (and its parent function in some case) that is being executed > when an interrupt is taken.
Well, it didn't fix the issue: # cat /sys/kernel/debug/tracing/stack_trace Depth Size Location (54 entries) ----- ---- -------- 0) 5096 16 irq_copy_thread_info+0x18/0x70 1) 5080 336 el1_irq+0x78/0x11c
<<<= _raw_spin_unlock_irqrestore
2) 4744 48 __skb_recv_datagram+0x148/0x49c 3) 4696 208 skb_recv_datagram+0x50/0x60 4) 4488 64 xs_udp_data_ready+0x48/0x170 5) 4424 96 sock_queue_rcv_skb+0x1fc/0x270 ... 53) 344 344 el0_svc_naked+0x20/0x28
__skb_recv_datagram+0x148 is "bl _raw_spin_unlock_irqrestore."
And the frames, #0 and #1, appear here because this patch replaces stack pointers *after* kernel_entry.
-Takahiro AKASHI
> > -Takahiro AKASHI > >> You can track down my report and Akashi's changes with the following links: >> - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html >> - https://lkml.org/lkml/2015/7/13/29 >> >> Although it is impossible to measure an exact depth at this moment, the feature >> could be utilized to check improvement. >> >> Cc'ing Akashi for additional comments if needed. >> >> Best Regards >> Jungseok Lee >>
| |