From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935071AbcKJQgP (ORCPT ); Thu, 10 Nov 2016 11:36:15 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:54037 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934104AbcKJQgN (ORCPT ); Thu, 10 Nov 2016 11:36:13 -0500 Subject: Re: Proposal: HAVE_SEPARATE_IRQ_STACK? To: "Jason A. Donenfeld" , Thomas Gleixner References: CC: LKML , , , WireGuard mailing list , From: Matt Redfearn Message-ID: Date: Thu, 10 Nov 2016 16:36:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.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 Hi Jason, On 10/11/16 11:41, Jason A. Donenfeld wrote: > On Thu, Nov 10, 2016 at 10:03 AM, Thomas Gleixner wrote: >> If you want to go with that config, then you need >> local_bh_disable()/enable() to fend softirqs off, which disables also >> preemption. > Thanks. Indeed this is what I want. > >>> What clever tricks do I have at my disposal, then? >> Make MIPS use interrupt stacks. > Yea, maybe I'll just implement this. It clearly is the most correct solution. > @MIPS maintainers: would you merge something like this if done well? > Are there reasons other than man-power why it isn't currently that > way? I don't see a reason not to do this - I'm taking a look into it. Thanks, Matt >> Does the slowdown come from the kmalloc overhead or mostly from the less >> efficient code? >> >> If it's mainly kmalloc, then you can preallocate the buffer once for the >> kthread you're running in and be done with it. If it's the code, then bad >> luck. > I fear both. GCC can optimize stack variables in ways that it cannot > optimize various memory reads and writes. > > Strangely, the solution that appeals to me most at the moment is to > kmalloc (or vmalloc?) a new stack, copy over thread_info, and fiddle > with the stack registers. I don't see any APIs, however, for a > platform independent way of doing this. And maybe this is a horrible > idea. But at least it'd allow me to keep my stack-based code the > same... >