From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752445AbbJBQYa (ORCPT ); Fri, 2 Oct 2015 12:24:30 -0400 Received: from foss.arm.com ([217.140.101.70]:41116 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbbJBQY3 (ORCPT ); Fri, 2 Oct 2015 12:24:29 -0400 Message-ID: <560EAF9F.6090604@arm.com> Date: Fri, 02 Oct 2015 17:23:59 +0100 From: James Morse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Jungseok Lee CC: Catalin Marinas , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "takahiro.akashi@linaro.org" , Mark Rutland , "barami97@gmail.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3] arm64: Introduce IRQ stack References: <1442923918-11289-1-git-send-email-jungseoklee85@gmail.com> In-Reply-To: <1442923918-11289-1-git-send-email-jungseoklee85@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 22/09/15 13:11, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces a system to use 16KB > stack, not 8KB one. This restriction makes low memory platforms suffer > from memory pressure accompanied by performance degradation. > > This patch addresses the issue as introducing a separate percpu IRQ > stack to handle both hard and soft interrupts with two ground rules: > > - Utilize sp_el0 in EL1 context, which is not used currently > - Do not complicate current_thread_info calculation > > It is a core concept to directly retrieve struct thread_info from > sp_el0. This approach helps to prevent text section size from being > increased largely as removing masking operation using THREAD_SIZE > in tons of places. One observed change in behaviour: Any stack-unwinding now stops at el1_irq(), which is the bottom of the irq stack. This shows up with perf (using incantation [0]), and with any calls to dump_stack() (which actually stops the frame before el1_irq()). I don't know if this will break something, (perf still seems to work) - but it makes the panic() output less useful, as all the 'other' cpus print: > CPU3: stopping > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.3.0-rc3+ #223 > Hardware name: ARM Juno development board (r1) (DT) > Call trace: > [] dump_backtrace+0x0/0x164 > [] show_stack+0x1c/0x28 > [] dump_stack+0x88/0xc8 > [] handle_IPI+0x258/0x268 > [] gic_handle_irq+0x88/0xa4 > Exception stack(0xffff8009769e3fc0 to 0xffff8009769e40e0) > <...values from stack ...> > CPU4: stopping > CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.3.0-rc3+ #223 > Hardware name: ARM Juno development board (r1) (DT) > Call trace: So we don't get to see what they were doing, as the IPI-irq and subsequent switch to the irq_stack hide the state. I was trying to fix this with the other version, (see the changes to kernel/stacktrace.c), but as Akashi Takahiro pointed out, I wasn't quite right... I will try to produce a fragment to tidy this up next week. Thanks, James [0] perf record -e mem:
:x -ag -- sleep 10; perf report --call-graph --stdio