netdev - Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 12:34:19 +0300
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
CC:	Mugunthan V N <mugunthanvnm@...com>, <linux-omap@...r.kernel.org>,
	<netdev@...r.kernel.org>, <kernel@...gutronix.de>
Subject: Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

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