From patchwork Mon Jan 4 22:27:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helge Deller X-Patchwork-Id: 7951661 Return-Path: X-Original-To: patchwork-linux-parisc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1AF93BEEE5 for ; Mon, 4 Jan 2016 22:28:22 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 47C6F20304 for ; Mon, 4 Jan 2016 22:28:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4147120303 for ; Mon, 4 Jan 2016 22:28:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753521AbcADW2T (ORCPT ); Mon, 4 Jan 2016 17:28:19 -0500 Received: from mout.gmx.net ([212.227.17.21]:61003 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753345AbcADW2Q (ORCPT ); Mon, 4 Jan 2016 17:28:16 -0500 Received: from p100.box ([92.203.21.165]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIyCj-1aEIjQ1rgH-002Ty2; Mon, 04 Jan 2016 23:28:01 +0100 Date: Mon, 4 Jan 2016 23:27:57 +0100 From: Helge Deller To: Thomas Gleixner , linux-parisc@vger.kernel.org, James Bottomley , John David Anglin Cc: Linux Kernel Development Subject: Re: timerfd_settime/timerfd_gettime issue ? Message-ID: <20160104222757.GA969@p100.box> References: <567E8766.6020707@gmx.de> <5682E96A.5040008@gmx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:EzBrpw1faS7Y4yWQzWQ+6KpY8BxNafUhIH2unnSRv1eO5/SZMj+ 7JwF5ing6kcgYDF/v36DXjQHhODujR0+D2TfEhE4Mjf/m3QqGQk45FjQkbVCT2H4LukzF2g cNGsyVX+7iyioF847sPqKwmjcuklucrSlJqggceNASrHgAGqG/o1s03oYti7U9C+iODXB9K bNLXoJMp5Q0+txa7xuAYQ== X-UI-Out-Filterresults: notjunk:1; V01:K0:WhVH9DTnENw=:tCLqghFHHGDFfyGDRxpk5c k12N1Lr+PUSUI2TYpIEXIeKVXx7dlZ0QOjscgfi+Ui33mB7lx52Jd2SvQEoeRJ4ZRWaVsBuHz XTl5y7AYsFyJWQPZHz8LRyakn44XfIugG1g/QDLZgF0+WwLDoCUPOZuMcP1wFW6il+rkCxPyQ JBd5WZTiMomBCzr7qadRcOoTgX3T0F2N8YHKGSHuIEIXWfev63VLdVwOgwv1ffuHueedDxdHT m7u1WIdoRDMiiwngX945C/iZFqzKkmaiJXFRrGPnZ594Uf7juilzgrvGGU/M/dKborHaoCp1o 7GV3qKLd2EbYaVAZh5PDviOjCPp5lrc3wcDOS4timb59+K2mBnRfxZqZU1yJVjHYG2Gi00IEO cEocxawLwTjNrU0bc4nxj0ANRZjDUsDO2wGzeuX7dy9HnKPCwOkreb05XTaSQelXPfUhj4hZg FRAFjTzWMHqJx/+idYTZj0t3ulq9j9Ny02D3g+D+EHEu6lXcpgvjKHQwkMnaAYQp+fNIIL5qS 1HO+guA9pW5AObbbKe/iX2Jx8mbvf9APAIC6RTOYeyfTks2Rt1Z6mfMpCVoRTITjxU3eBzq9H uckXatK8iAwlrvgfoGtMQBZecrKo2cbQafGWNG3kogvJe4Bztka9bDnY8CMPOJ45xXw2FJw+w dng9gCvS5N1AWlSdF6GL2ky+F+GsDzIYvfqQz6xHy0ILQ7AagFxvAkuWhKJ8Efj5ervf7t01p pmu0JIzG8LR4djjAuAo64NNVo+SRRi9hwk1FU1N1AKJFcOFvCeDPjoWPbs8= Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Thomas, * Thomas Gleixner : > On Tue, 29 Dec 2015, Helge Deller wrote: > > No, the patch below doesn't help. > > > > I still see: > > [ 644.916000] timerfd_settime: interval (sec=0, nsec=100000000) it_value (sec=0, nsec=100000000) > > [ 645.024000] timerfd_gettime: interval (sec=0, nsec=100000000) it_value (sec=0, nsec=103029949) > > > > Right. It can't help. Sorry for the distraction. > > Looking deeper I found the issue. It's caused by CONFIG_TIME_LOW_RES. See the > comment in hrtimer_start_range_ns(). We round the expiry time to the next > jiffies period to avoid short timeouts. Assuming you are running with HZ=250 > this is exactly 4ms. So that's where your extra time comes from. Yes, that seems right. > Not sure what to do about that. The patch below seems to solve the issue for me. But I'm not sure if there might be any side-effects. What do you think? Does the patch seems correct? It just adjusts to values returned to userspace (and thus hides the internal roundings). Thanks, Helge --- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/timerfd.c b/fs/timerfd.c index b94fa6c..9b6cc73 100644 --- a/fs/timerfd.c +++ b/fs/timerfd.c @@ -152,8 +152,16 @@ static ktime_t timerfd_get_remaining(struct timerfd_ctx *ctx) if (isalarm(ctx)) remaining = alarm_expires_remaining(&ctx->t.alarm); - else + else { remaining = hrtimer_expires_remaining(&ctx->t.tmr); +#ifdef CONFIG_TIME_LOW_RES + /* Expiry time was rounded up in hrtimer_start_range_ns() + * to the next jiffies period to avoid short timeouts. + * Subtract it here again to avoid userspace seeing higher + * values than expected. */ + remaining.tv64 -= hrtimer_resolution; +#endif + } return remaining.tv64 < 0 ? ktime_set(0, 0): remaining; }