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]

Message-Id: <1166034960.1785.10.camel@localhost.localdomain>
Date:	Wed, 13 Dec 2006 13:36:00 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	tike64 <tike64@...oo.com>
Cc:	junjiec@...il.com, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: realtime-preempt and arm

For -rt issues, please CC Ingo Molnar, and for High Res issues, please
CC Thomas Gleixner.

On Fri, 2006-12-01 at 01:07 -0800, tike64 wrote:
> > Hi,
> > 
> > Without the support of High Resolution Timer
> > supported, the timer resolution wouldn't change.
> 
> Ok, I understand that. I was not expecting more
> resolution. I expected only that I would get more
> precise 10ms delays. What confuses me is that the
> delays roughly doubled.
> 
> > With high-resolution-timer supported, our
> > arm926-based board could get resolution like
> 40~50us.
> > There are codes you can reference ,may be you should
> > just try to implement it.
> 
> It is good to know that the problem is not the arm
> architecture itself. Thanks to you for that.
> 
> The problem must be in the lh7a40x specific code or my
> configuration. I am not yet convinced enough that high
> resolution timer implementation would solve the
> problem. I don't need timing resolution finer than
> 10ms providing that FB doesn't blow it up to 60ms.
> 
> Could you or someone please give a hint where to look
> next or give an explanation why the lack of high
> resolution timer would behave like that.

Also, have you tried this with a nanosleep instead of a select.
Select's timeout is just that, a timeout. It's not suppose to be
accurate, as long as it doesn't expire early.  The reason I state this,
is that select uses a different mechanism than nanosleep, and that can
indeed affect the jitter.

Although without the high res enabled, you can't get better than jiffy
resolution, you shouldn't get a large jitter either.  BTW, using high
res won't help the select anyway. The select uses a normal
schedule_timeout, which means that it's not really expected to timeout,
but something should wake it up before hand. Which means that the good
old timer wheel (non-hrtimer) is going to do the waking of the process.
This means that you need to wait for the timer softirq to be scheduled
before your process wakes up. If there's a process with a higher
priority than the timer softirq running, then you need to wait.

Using nansleep uses the hrtimer code (available with out the high
resolutions).  The hrtimer uses its own timer softirq (softirq-hrtimer),
and it is special.  It inherits the priority of the task that created
the timer when the timer goes off.  Also, something like nanosleep,
won't even use the softirq, and will bypass the softirq all together,
and wake your process up from the interrupt.

So basically, don't use select for timing.

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