From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755254Ab0IHOiO (ORCPT ); Wed, 8 Sep 2010 10:38:14 -0400 Received: from gw1.transmode.se ([213.115.205.20]:40174 "EHLO gw1.transmode.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750883Ab0IHOiM (ORCPT ); Wed, 8 Sep 2010 10:38:12 -0400 In-Reply-To: References: <1283934289.2880.12.camel@edumazet-laptop> <1283950818.23762.20.camel@laptop> Subject: Re: slow nanosleep? X-KeepSent: D443E2A6:F61EE9A0-C1257798:004FDA4F; type=4; name=$KeepSent To: Thomas Gleixner Cc: Eric Dumazet , linux-kernel@vger.kernel.org, Peter Zijlstra X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 Message-ID: From: Joakim Tjernlund Date: Wed, 8 Sep 2010 16:33:15 +0200 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5.1FP3|May 23, 2010) at 2010-09-08 16:38:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner wrote on 2010/09/08 16:30:07: > > On Wed, 8 Sep 2010, Joakim Tjernlund wrote: > > Thomas Gleixner wrote on 2010/09/08 15:52:23: > > > On Wed, 8 Sep 2010, Joakim Tjernlund wrote: > > > > > > > > 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; > > That actually will return for any expiry time. The timer is armed in > do_nanosleep() not in hrtimer_set_expires_tv64() / > hrtimer_set_expires_range_ns() eehh, I should have tested with bigger nanosleeps as well :(