Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp416867imm; Fri, 14 Sep 2018 00:02:18 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZWyGb46DOWRmL774K0oSyi7CnPnUVDXqsmWyThLYP9ys5pXtECf5CxdK8pjh8nWZ359nQL X-Received: by 2002:a17:902:22:: with SMTP id 31-v6mr10615896pla.190.1536908538370; Fri, 14 Sep 2018 00:02:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536908538; cv=none; d=google.com; s=arc-20160816; b=aW/kKsZkcldX8ZthXOy7GKlNiPXQWdVOERl4US/l7ahVguk8xy59IcLTHKncf2w5UP Y9DMwbszfCnI1uwqwRH2eiDzlmSMDzUqC2wyP1W02JN+0mz34uU2q862gjBeb+jCZb/S 0IudHB1y2eWHrvB0zY2Qp/9Du07AFIlOZh0fEWFwu/2m7IwVb31ZgRaoYyCcEzuLrm0r Opz/v4dAI36QUFA3VTD3y9vvP1Odwsap8wUeJH1dWYVSix7HruwwA3yziSSRXV2m02Ce oB3mYrc9Kju06fKSrp1TFlh+Tm+TLwuog1KRQl1unkqMExIfa3QZmB9swY/2stAfri3V w+lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=X8hE2HFO09Pjyu0NioPu3SWwNygjWgUw48MQr4iNTjg=; b=GS0gl5ZRInkdlCflsY+W5H9TZmjuOJjPW+TmFRa6GcdT7JSoHFaLHbmcOqcl5418Fp Lfg5r66i/SVZbf258vhw6jvnXdFGeMOjEyNhFMQnZgdt9WF/VBfYXRtiKhJwabYPCaS1 tMFwFzO0U4Ymcua2fWqTV9nrK6zOkL9BxWbADV4lT/nhYkwoi0efVm9uUvjgcaF/MZ0w PehuN0/o95C9FDbm9C9cUlfiUBZL1SHwVo4Z0X6j2advCDImDK4n5CPZvJy3knoFYYqG WFv3GfidCBfLLESaEI8/jT36h01Fbv4/MDdATVyNfTqp6u8ZOzTxdOL3g2kCEf5EpLd1 Sabg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f21-v6si6510445pgk.418.2018.09.14.00.02.02; Fri, 14 Sep 2018 00:02:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727649AbeINMOv (ORCPT + 99 others); Fri, 14 Sep 2018 08:14:51 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:58761 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726822AbeINMOu (ORCPT ); Fri, 14 Sep 2018 08:14:50 -0400 Received: from 79.184.255.178.ipv4.supernova.orange.pl (79.184.255.178) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.148) id f76cb641916a1a90; Fri, 14 Sep 2018 09:01:43 +0200 From: "Rafael J. Wysocki" To: Linux PM Cc: Linux ACPI , LKML , Mika Westerberg , Peter Zijlstra , Thomas Gleixner , Srinivas Pandruvada , Vitaly Kuznetsov Subject: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time Date: Fri, 14 Sep 2018 08:59:03 +0200 Message-ID: <9611469.2z7W9akjOQ@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki There is a difference in behavior between suspend-to-idle and suspend-to-RAM in the timekeeping handling that leads to functional issues. Namely, every iteration of the loop in s2idle_loop() increases the monotinic clock somewhat, even if timekeeping_suspend() and timekeeping_resume() are invoked from s2idle_enter(), and if many of them are carried out in a row, the monotonic clock can grow significantly while the system is regarded as suspended, which doesn't happen during suspend-to-RAM and so it is unexpected and leads to confusion and misbehavior in user space (similar to what ensued when we tried to combine the boottime and monotonic clocks). To avoid that, count all iterations of the loop in s2idle_loop() as "sleep time" and adjust the clock for that on exit from suspend-to-idle. [That also covers systems on which timekeeping is not suspended by by s2idle_enter().] Signed-off-by: Rafael J. Wysocki --- This is a replacement for https://patchwork.kernel.org/patch/10599209/ I decided to count the entire loop in s2idle_loop() as "sleep time" as the patch is then simpler and it also covers systems where timekeeping is not suspended in the final step of suspend-to-idle. I dropped the "Fixes:" tag, because the monotonic clock delta problem has been present on the latter since the very introduction of "freeze" (as suspend-to-idle was referred to previously) and so this doesn't fix any particular later commits. --- kernel/power/suspend.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) Index: linux-pm/kernel/power/suspend.c =================================================================== --- linux-pm.orig/kernel/power/suspend.c +++ linux-pm/kernel/power/suspend.c @@ -109,8 +109,12 @@ static void s2idle_enter(void) static void s2idle_loop(void) { + ktime_t start, delta; + pm_pr_dbg("suspend-to-idle\n"); + start = ktime_get(); + for (;;) { int error; @@ -150,6 +154,20 @@ static void s2idle_loop(void) pm_wakeup_clear(false); } + /* + * If the monotonic clock difference between the start of the loop and + * this point is too large, user space may get confused about whether or + * not the system has been suspended and tasks may get killed by + * watchdogs etc., so count the loop as "sleep time" to compensate for + * that. + */ + delta = ktime_sub(ktime_get(), start); + if (ktime_to_ns(delta) > 0) { + struct timespec64 timespec64_delta = ktime_to_timespec64(delta); + + timekeeping_inject_sleeptime64(×pec64_delta); + } + pm_pr_dbg("resume from suspend-to-idle\n"); }