mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Dag Nygren <dag@newtech.fi>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nanosleep with small value
Date: Thu, 17 Nov 2005 11:17:48 -0800	[thread overview]
Message-ID: <29495f1d0511171117veebf091ja2277a73ec40af2f@mail.gmail.com> (raw)
In-Reply-To: <20051117191119.15126.qmail@dag.newtech.fi>

On 11/17/05, Dag Nygren <dag@newtech.fi> wrote:
> > On 11/17/05, Dag Nygren <dag@newtech.fi> wrote:
>
> > > The man page for nanosleep saya that times under 2 us are implemented
> > > by a busywait and  this is why I expected it to work.
> >
> > Update your manpages. You're depending on 2.4 behavior in a 2.6 kernel.
>
> You are right. The system is one I have upgraded piece by piece and the
> manpages
> weren't upgraded.

No problem.

> But what is the point of having a nanosleep() in that case when you could do
> just fine with usleep() ?

Check the usleep() manpage:

This function is obsolete. Use nanosleep(2) or setitimer(2) instead.

And in any case, I think usleep() just ends up calling nanosleep()?
It's not a sys-call in an of itself, like sys_nanosleep().

> > > OK, in that case the manpage should be changed. And an alternative
> > > has to be worked out by me ;-).
> >
> > My man-pages are quite clear on what nanosleep() does. Nothing needs
> > to be changed there.
> >
> > Alternative wise, I'm not sure, but you might want to look into the
> > HRT stuff that's going on in Ingo's -RT tree. I don't know if / what
> > changes have been made to sys_nanosleep(), but low-latency is most
> > likely to occur there.
>
> I will look into that.
> Quite annoying that software that worked just fine in 2.4 doesn't
> work in 2.6.

Well, your general resolution also was improved quite a bit in 2.6
(HZ=1000 vs. HZ=100 is a 10-fold improvement). But I agree, is a big
difference if you depend on that udelay() functionality -- but it was
a delay of up to 2 milliseconds, which is generally frowned upon in
the kernel.

> What does POSIX say about nanosleep()?

Not sure, but I think the only requirement is that we don't return
early (i.e. request 2 milliseconds, return in 1 millisecond).

Thanks,
Nish

  parent reply	other threads:[~2005-11-17 19:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <29495f1d0511171051q6088099drfe094817a01668e4@mail.gmail.com>
2005-11-17 19:11 ` Dag Nygren
2005-11-17 19:15   ` Randy.Dunlap
2005-11-17 19:17   ` Nish Aravamudan [this message]
2005-11-17 19:47   ` Frank Sorenson
2005-11-21  7:12     ` Dag Nygren
2005-11-17 20:25 Dag Nygren
  -- strict thread matches above, loose matches on Subject: below --
2005-11-17 16:30 Dag Nygren
2005-11-17 16:55 ` linux-os (Dick Johnson)
2005-11-17 17:32   ` Eric Piel
2005-11-17 17:12 ` Nish Aravamudan
2005-11-17 18:47   ` Dag Nygren

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=29495f1d0511171117veebf091ja2277a73ec40af2f@mail.gmail.com \
    --to=nish.aravamudan@gmail.com \
    --cc=dag@newtech.fi \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®