All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Timur Tabi <timur@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v5] introduce macro spin_event_timeout()
Date: Wed, 11 Mar 2009 11:24:57 +1100	[thread overview]
Message-ID: <1236731097.7086.32.camel@pasglop> (raw)
In-Reply-To: <ed82fe3e0903101722i610638e8le1f2e925095c8ba6@mail.gmail.com>

On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
> 
> Alan did have one valid point though.  Determining how long to loop
> for is architecture-specific.  Using jiffies is bad, because even one
> jiffy is too long.  Adding a udelay() inside the loop means that it
> only checks he condition every microsecond.  So the real solution is
> to use keep looping until a certain amount of time has passed.  This
> means using an architecture-specific timebase register.

> Now we can create a generic version of the function that uses jiffies,
> and then arch-specific versions where possible.  But Alan still needs
> to be convinced.  I already posted a length rebuttal to his email, but
> I haven't gotten a reply yet.
> 
There are several aspects here:

 - The amount of time to wait should be specified by the caller since
it's generally going to come from HW specs

 - The amount of time between the polls ... that could also be an
argument to the macro, not sure there

 - The precision of the actual wait calls... I vote for microseconds for
everything and udelay. The arch will do its best.

Cheers,
Ben.

  reply	other threads:[~2009-03-11  0:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-10 22:11 [PATCH v5] introduce macro spin_event_timeout() Timur Tabi
2009-03-10 22:33 ` Scott Wood
2009-03-10 22:37   ` Josh Boyer
2009-03-10 22:58     ` Scott Wood
2009-03-11  0:32       ` Josh Boyer
2009-03-10 23:59     ` Benjamin Herrenschmidt
2009-03-11  0:22       ` Timur Tabi
2009-03-11  0:24         ` Benjamin Herrenschmidt [this message]
2009-03-11 17:10           ` Grant Likely
2009-03-11 21:49             ` Benjamin Herrenschmidt
2009-03-11 21:54               ` Timur Tabi
2009-03-11 22:49                 ` Scott Wood
2009-03-11  5:09         ` Roland Dreier
2009-03-11 16:31           ` Timur Tabi
2009-03-11 16:51             ` Scott Wood
2009-03-11 19:14               ` Timur Tabi
2009-03-11 19:22                 ` Scott Wood
2009-03-11 20:45                   ` Timur Tabi
2009-03-11 21:00                     ` Scott Wood
2009-03-11 21:02                       ` Timur Tabi
2009-03-11 21:03                         ` Scott Wood
2009-03-11  0:44       ` Josh Boyer
2009-03-10 23:58 ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1236731097.7086.32.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    --cc=timur@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.