On 07/27/2016 05:38 PM, Uwe Kleine-König wrote: > Hello, > > On Wed, Jul 27, 2016 at 05:11:54PM +0300, Grygorii Strashko wrote: >> On 07/27/2016 10:03 AM, Uwe Kleine-König wrote: >>> On Tue, Jul 26, 2016 at 05:36:49PM +0300, Grygorii Strashko wrote: >>>> On 07/26/2016 03:02 PM, Uwe Kleine-König wrote: >>>>> Hello, >>>>> >>>>> these patches are based on next-20160726. I didn't check yet how latency >>>>> improves by using these patches, but even if the improvment is small, >>>>> it's still a good idea to have them. >>>> >>>> Sry, but how this will affect on -RT? This is not a raw locks, so >>>> they will be converted to rt-mutexes which are sleepable. >>>> Or I've missed smth? >>> >>> They are still locks after all. On -rt I saw for the relevant >>> application: >>> >>> send package | >>> take lock | >>> write pckt to hw | >>> | rcv irq >>> | take lock >>> | schedule >>> drop lock | >>> schedule | >>> | get pckt from hw >>> | drop lock >>> >>> So reducing the time a lock is taken reduces the chances that the lock >>> is contended for another thread which results in extra context switches. >>> >> Thanks a lot for explanation. So, this is not exactly rt-latency reduction, >> but it might improve net performance on -RT. correct? > > Well, it's not really rt related, but if you hit a locked lock on rt it > hurts more than on !rt. And this results in increased latency. >
Thanks. I've just wanted to have clear understanding of the [possible] issue. And I'd be appreciated if you could share and measurement results if you have. -- regards, -grygorii
