Messages in this thread | | | Subject | Re: Proposal: HAVE_SEPARATE_IRQ_STACK? | From | Matt Redfearn <> | Date | Thu, 10 Nov 2016 16:36:10 +0000 |
| |
Hi Jason,
On 10/11/16 11:41, Jason A. Donenfeld wrote: > On Thu, Nov 10, 2016 at 10:03 AM, Thomas Gleixner <tglx@linutronix.de> 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... >
| |