linux-kernel - Re: [PATCH v4] introduce macro spin_event

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] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 22:51:10 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Timur Tabi <timur@...escale.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, rdreier@...co.com,
	jirislaby@...il.com, will.newton@...il.com, hancockrwd@...il.com,
	jeremy@...p.org
Subject: Re: [PATCH v4] introduce macro spin_event_timeout()

On Thu, Mar 12, 2009 at 9:03 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
>
>> But that's the thing - I don't want a required delay inside the loop.
>>
>> I guess I'm going to have to think about this for a while.  I'd like
>> to see something like cycles_per_usec() as a companion function to
>> get_cycles().
>
> I think that's where you're wrong :-)

And I disagree.  :-)

> Just require the delay inside the loop, it will make everything nicer.
> There are also some good reasons to do that:
>
>  - The delay between "polls" of the register may have to be controlled,
> for example some HW will choke if polled too fast

Yes, but not all HW does.  There have been several times that I've
needed to spin on a register without any delay.  Requiring the loop
block to include an explicit delay nullifies most of usefulness to me.

>  - If you aren't in an atomic section, you may want to use msleep() and
> thus be schedule friendly

This I agree with, and I see a real use for.  However, if the contents
of the block don't have any form of constant delay, then it is less
clear how long the loop is going to run for.

OTOH, for the kind of delays that I see myself using it for, it if
doesn't have a resolution in the range of timebase ticks, then it
probably isn't going to be useful for me.  I certainly am not
interested in spinning for more than a handful of ticks if I can help
it.

>  - It fixes all the problems mentioned earlier

On another note; I'd consider calling it loop_event_timeout() instead
of spin_event_timeout() since it would allow the block contents to
sleep, and hence it wouldn't be spinning anymore.  :-)

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/