From: Sebastian Andrzej Siewior > Sent: 01 May 2020 11:42 > On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote: > > Sometimes it's not okay to use SIMD registers, the conditions for which > > have changed subtly from kernel release to kernel release. Usually the > > pattern is to check for may_use_simd() and then fallback to using > > something slower in the unlikely case SIMD registers aren't available. > > So, this patch fixes up i915's accelerated memcpy routines to fallback > > to boring memcpy if may_use_simd() is false. > > That would indicate that these functions are used from IRQ/softirq which > break otherwise if the kernel is also using the registers. The crypto > code uses it for that purpose. > > So > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > > May I ask how large the memcpy can be? I'm asking in case it is large > and an explicit rescheduling point might be needed. It is also quite likely that a 'rep movs' copy will be at least just as fast on modern hardware. Clearly if you are copying to/from PCIe memory you need the largest resisters possible - but I think the graphics buffers are mapped cached? (Otherwise I wouldn't see 3ms 'spins' while it invalidates the entire screen buffer cache.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
