linux-kernel - Re: slow nanosleep?

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:	Wed, 8 Sep 2010 16:19:13 +0200
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: slow nanosleep?



Thomas Gleixner <tglx@...utronix.de> wrote on 2010/09/08 15:52:23:

> From: Thomas Gleixner <tglx@...utronix.de>
> To: Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
> Cc: Peter Zijlstra <peterz@...radead.org>, Eric Dumazet
> <eric.dumazet@...il.com>, linux-kernel@...r.kernel.org
> Date: 2010/09/08 15:52
> Subject: Re: slow nanosleep?
>
> On Wed, 8 Sep 2010, Joakim Tjernlund wrote:
>
> > Peter Zijlstra <peterz@...radead.org> wrote on 2010/09/08 15:00:18:
> > >
> > > On Wed, 2010-09-08 at 14:43 +0200, Thomas Gleixner wrote:
> > > > > However nanosleep with 1 ns and prctl(PR_SET_TIMERSLACK, 1) takes
> > > > > about 8 us on x86(Intel(R) Core(TM)2 Duo CPU E8500  @ 3.16GHz)
> > > > > and 20 us on my slower ppc board. Is that system call overhead
> > > > > or possibly some error?
> > > >
> > > > That's overhead I fear. We go way up to enqueue/arm the timer until we
> > > > figure out that the timeout already happened.
> > >
> > > Well, there's also the fact that his ppc board is simply dead slow,
> > > using the freq ratio: 3166/266 you'd expect (at a similar ins/clock
> > > ratio) the ppc to take 95us.
> > >
> > > So in fact the pcc taking 20us is actually quite good.
> >
> > Actually, it takes 120 us. The 20 us was when I had Thomas
> > timeout == 0 fast path patch applied(forgot to remove it).
> > Without that patch it takes about 115 us. So it seems it takes
> > 115-20=95 us to turn the timer wheel on my ppc.
>
> You might fire up the tracer to look where it spends that time.

This helps for short(1 ns) nanosleeps, sleeps for 25 us. No idea
if this is any good, just tossing it out for you to tear apart :)

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 5c69e99..e612016 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1545,6 +1545,9 @@ long __sched hrtimer_nanosleep_restart(struct restart_block *restart)
 				HRTIMER_MODE_ABS);
 	hrtimer_set_expires_tv64(&t.timer, restart->nanosleep.expires);

+	if (!hrtimer_active(&t.timer))
+		goto out;
+
 	if (do_nanosleep(&t, HRTIMER_MODE_ABS))
 		goto out;

@@ -1576,6 +1579,9 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,

 	hrtimer_init_on_stack(&t.timer, clockid, mode);
 	hrtimer_set_expires_range_ns(&t.timer, timespec_to_ktime(*rqtp), slack);
+	if (!hrtimer_active(&t.timer))
+		goto out;
+
 	if (do_nanosleep(&t, mode))
 		goto out;



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