From: Peter Lafreniere > Sent: 06 December 2022 14:04 > > > > > BTW, just a minor nit but you can delete the cond_resched() call > > > > because kernel_fpu_end()/preempt_enable() will do it anyway. > > > > > > That happens under > > > CONFIG_PREEMPTION=y > > > (from include/Linux/preempt.h and arch/x86/include/asm/preempt.h) > > > > > > Is calling cond_resched() still helpful if that is not the configuration? > > > > > > Perhaps, but then again perhaps if preemption is off, maybe we > > shouldn't even bother with the 4K split. Were the initial > > warnings with or without preemption? > > > > Personally I don't really care since I always use preemption. > > > > The PREEMPT Kconfigs do provide a bit of nuance with the split > > between PREEMPT_NONE vs. PREEMPT_VOLUNTARY. But perhaps that is > > just overkill for our situation. > > I was thinking about this a few days ago, and my 2¢ is that it's > probably best to not preempt the kernel in the middle of a crypto > operation under PREEMPT_VOLUNTARY. We're already not preempting during > these operations, and there haven't been complaints of excessive latency > because of these crypto operations. ... Probably because the people who have been suffering from (and looking for) latency issues aren't running crypto tests. I've found some terrible pre-emption latency issues trying to get RT processes scheduled in a sensible timeframe. I wouldn't worry about 100us - I'm doing audio processing every 10ms, but anything much longer causes problems when trying to use 90+% of the cpu time for lots of audio channels. I didn't try a CONFIG_RT kernel, the application needs to run on a standard 'distro' kernel. In any case I suspect all the extra processes switches (etc) the RT kernel adds will completely kill performance. I wonder how much it would cost to measure the time spent with pre-empt disabled (and not checked) and to trace long intervals. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
