Re: Proposal: HAVE_SEPARATE_IRQ_STACK?
From: Matt Redfearn <hidden>
Date: 2016-11-10 16:36:15
Also in:
linux-mm, lkml
Hi Jason, On 10/11/16 11:41, Jason A. Donenfeld wrote:
On Thu, Nov 10, 2016 at 10:03 AM, Thomas Gleixner [off-list ref] wrote:quoted
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.quoted
quoted
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
quoted
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...