linux-kernel - Re: realtime-preempt and arm

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, 14 Dec 2006 07:52:02 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	tike64 <tike64@...oo.com>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: realtime-preempt and arm

On Thu, 14 Dec 2006, tike64 wrote:

> Ingo Molnar <mingo@...e.hu> wrote:
> > tike64 <tike64@...oo.com> wrote:
> > > Ok, understood; I tried this:
> > >
> > > 	t = raw_timer();
> > > 	ts.tv_nsec = 5000000;
> > > 	ts.tv_sec = 0;
> > > 	nanosleep(&ts, 0);
> > > 	t = raw_timer() - t;
> > >
> > > It is better but I still see 8ms occasional delays when listing
> > > nfs-mounted directories onto FB. And, what is funny, also this
> > > version makes the average delay 20ms as if it made the jiffy 20ms.
> >
> > ARM has no high resolution timers support yet in the -rt tree.
>
> Yes, but is there a reason why the -rt patch seems to make the 10ms
> jiffy 20ms and why the jitter is so high. I don't need high resolution
> but reasonable, a couple of milliseconds, jitter.
>

OK, let me see if I get this right.  You have jiffies at 100HZ right? So
that means the timer needs to go off at 10ms intervals. So you are always
seeing a jiffy+1 delay?  Well this unfortunately has to happen, since it's
ok for the timer to be a little over, but it must never be a little under.
Lets add some ASCII graphics to this :)

         10ms      20ms          (n+10)ms     (n+11)ms
|---------+---------+---- .... ---+---------+--->
                 ^                  ^
               Start               End

OK, here we have a timer that should go off in (n)ms. We start between
10ms and 20ms (remember, our resolution is only 10ms).  If we just make
the timer go off at 10+n ms in the future, you get the above.  But notice,
that the Start was really closer to 20 than to 10, so the End really
didn't go off in (n)ms. It went off in less. So to solve this, we must add
one resolution time to the counter. So we make sure the timer goes off in
(n+1) ms, and not just (n).

Is this what you're seeing?

Note, even with high resolution timers, you still get a resolution+1 time.
But with high resolution timers, that resolution number is much smaller
than 10ms :)

-- Steve

-
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/