RE: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux