On Thu, 10 Nov 2016, Jason A. Donenfeld wrote: > Hey Thomas, > > On Wed, Nov 9, 2016 at 10:40 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > That preempt_disable() prevents merily preemption as the name says, but it > > wont prevent softirq handlers from running on return from interrupt. So > > what's the point? > > Oh, interesting. Okay, then in that case the proposed define wouldn't > be useful for my purposes. If you want to go with that config, then you need local_bh_disable()/enable() to fend softirqs off, which disables also preemption. > What clever tricks do I have at my disposal, then? Make MIPS use interrupt stacks. > >> If not, do you have a better solution for me (which doesn't > >> involve using kmalloc or choosing a different crypto primitive)? > > > > What's wrong with using kmalloc? > > It's cumbersome and potentially slow. This is crypto code, where speed > matters a lot. Avoiding allocations is usually the lowest hanging > fruit among optimizations. To give you some idea, here's a somewhat > horrible solution using kmalloc I hacked together: [1]. I'm not to > happy with what it looks like, code-wise, and there's around a 16% > slowdown, which isn't nice either. 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. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>