Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933141AbcKJNDM (ORCPT ); Thu, 10 Nov 2016 08:03:12 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:33101 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932295AbcKJNDL (ORCPT ); Thu, 10 Nov 2016 08:03:11 -0500 Date: Thu, 10 Nov 2016 14:00:33 +0100 (CET) From: Thomas Gleixner To: "Jason A. Donenfeld" cc: LKML , linux-mips@linux-mips.org, linux-mm@kvack.org, WireGuard mailing list , k@vodka.home.kg Subject: Re: Proposal: HAVE_SEPARATE_IRQ_STACK? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1162 Lines: 30 On Thu, 10 Nov 2016, Jason A. Donenfeld wrote: > On Thu, Nov 10, 2016 at 10:03 AM, Thomas Gleixner wrote: > > 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. The question is how much of it is code and how much of it is the kmalloc. > 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... Do not even think about going there. That's going to be a major mess. As a short time workaround you can increase THREAD_SIZE_ORDER for now and then fix it proper with switching to seperate irq stacks. Thanks, tglx