linux-kernel - Re: [PATCH RFC] staging: wilc1000: give usleep

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:   Wed, 10 Apr 2019 18:31:21 +0000
From:   <Adham.Abozaeid@...rochip.com>
To:     <der.herr@...r.at>
CC:     <hofrat@...dl.org>, <Ajay.Kathat@...rochip.com>,
        <gregkh@...uxfoundation.org>, <linux-wireless@...r.kernel.org>,
        <devel@...verdev.osuosl.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] staging: wilc1000: give usleep_range a range

Hi Nicolas

On 4/8/19 6:36 PM, Nicholas Mc Guire wrote:
> On Mon, Apr 08, 2019 at 09:10:00PM +0000, Adham.Abozaeid@...rochip.com wrote:
>> Hi Nicholas
>>
>> On 4/6/19 5:01 AM, Nicholas Mc Guire wrote:
>>> External E-Mail
>>>
>>>
>>> Someone that knows the motivation for setting the time to 2 millisecond
>>> might need to check if the 2 milliseconds where seen as tollerable max or
>>> min - I'm assuming it was the min so extending.
>> 2 msec is the time the chip takes to wake up from sleep.
>>
>> Increasing the maximum to 5 msec will impact the throughput since this call is on the transmit path.
>>
> ok - would it be tollerable to make it 2 - 2.5 ms ?
> even that would allow for the hrtimer subsystem to optimize
> a lot. In any case the min==max case gives you very little
> if you run a test-case with usleep_range(1000,1000) and
> a loop with usleep_range(1000,2000) and look at the distribution
> you will have a hard time seeing any difference.

yes, I believe 2.5 shouldn't be a problem.

Thanks,

Adham