Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752715AbcLGJa1 (ORCPT ); Wed, 7 Dec 2016 04:30:27 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:46779 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752588AbcLGJa0 (ORCPT ); Wed, 7 Dec 2016 04:30:26 -0500 Subject: Re: [PATCH 0/5] MIPS: Add per-cpu IRQ stack To: "Jason A. Donenfeld" References: <1480685957-18809-1-git-send-email-matt.redfearn@imgtec.com> CC: Ralf Baechle , , Thomas Gleixner , Paolo Bonzini , Marcin Nowakowski , Chris Metcalf , Petr Mladek , LKML , Andrea Gelmini , James Hogan , Paul Burton , Jiri Slaby , "Maciej W. Rozycki" , Aaron Tomlin , Andrew Morton From: Matt Redfearn Message-ID: <9f778311-6d4d-cc57-00db-db2141803416@imgtec.com> Date: Wed, 7 Dec 2016 09:30:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.150.130.83] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2905 Lines: 78 Hi Jason, On 06/12/16 22:09, Jason A. Donenfeld wrote: > Hi Matt, > > Thanks for submitting this. A happy OpenWRT/WireGuard user has > reported to me that this patch set frees ~1300 bytes of stack on a > small MIPS router. This kind of savings should allow me to reintroduce > my crypto operations to be on the stack, rather than the conditional > MIPS kmallocing, which will be a performance win. Excellent. > > By the way, it looks like x86 and SPARC have separately allocated hard > IRQ and soft IRQ stacks. ARM has only one for both, similar to this > MIPS patchset. The separate stack for soft-IRQs could be added as well, but of course there is a tradeoff against the additional memory consumed by it. I believe that most soft IRQs will now be handled on the new irq stack, because HAVE_IRQ_EXIT_ON_IRQ_STACK causes them to be invoked within irq_exit, while still executing on the irq stack Thanks, Matt > > Jason > > On Fri, Dec 2, 2016 at 2:39 PM, Matt Redfearn wrote: >> This series adds a separate stack for each CPU wihin the system to use >> when handling IRQs. Previously IRQs were handled on the kernel stack of >> the current task. If that task was deep down a call stack at the point >> of the interrupt, and handling the interrupt required a deep IRQ stack, >> then there was a likelihood of stack overflow. Since the kernel stack >> is in normal unmapped memory, overflowing it can lead to silent >> corruption of other kernel data, with weird and wonderful results. >> >> Before this patch series, ftracing the maximum stack size of a v4.9-rc6 >> kernel running on a Ci40 board gave: >> 4996 >> >> And with this series: >> 4084 >> >> Handling interrupts on a separate stack reduces the maximum kernel stack >> usage in this configuration by ~900 bytes. >> >> Since do_IRQ is now invoked on a separate stack, we select >> HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirqs will also be executed on the >> irq stack rather than attempting to switch with do_softirq_own_stack(). >> >> This series has been tested on MIPS Boston, Malta and SEAD3 platforms, >> Pistachio on the Creator Ci40 board and Cavium Octeon III. >> >> >> >> Matt Redfearn (5): >> MIPS: Introduce irq_stack >> MIPS: Stack unwinding while on IRQ stack >> MIPS: Only change $28 to thread_info if coming from user mode >> MIPS: Switch to the irq_stack in interrupts >> MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK >> >> arch/mips/Kconfig | 1 + >> arch/mips/include/asm/irq.h | 12 ++++++ >> arch/mips/include/asm/stackframe.h | 10 +++++ >> arch/mips/kernel/asm-offsets.c | 1 + >> arch/mips/kernel/genex.S | 81 +++++++++++++++++++++++++++++++++++--- >> arch/mips/kernel/irq.c | 11 ++++++ >> arch/mips/kernel/process.c | 15 ++++++- >> 7 files changed, 125 insertions(+), 6 deletions(-) >> >> -- >> 2.7.4 >>