Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1001504ybi; Wed, 19 Jun 2019 11:34:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZAi/e4Fqe3/qRjhlfvD0oNHuknkw5mYziAzjIulmtagEa3peYZGZ6ckrLpwkfDLc+CL61 X-Received: by 2002:a17:902:31c3:: with SMTP id x61mr5475723plb.331.1560969261489; Wed, 19 Jun 2019 11:34:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560969261; cv=none; d=google.com; s=arc-20160816; b=FjTy5/ujAKSxYdhaLz/GJ0kS6bp17WW6wbQ1LyupwsMWySVinKjsuVcUUWY+4HZNus FXItpS2RtQnnsZ8ndeT86Eu4WxJq++6Ekn/JPxLqHq0HCWcjwMUqf3lEIxdmUcobasA4 wyKC32KS4M1zIaD2atj643g/o/tqQN6fcD0yIAn/qrO/DhE3mraO9G74+R67Rk8zHuVg QvsTPPTAzLRdBVsiJtwKdDAOHohqJEehN2H4b/p79y1zyxQgfVQ63Q1B167ZLzsyz3CU 2Wg6tnEUpBGPOEhEaL8tMLSb65+7iqEPpmqC0V/vILLFGdazAIyioJFN5UfCZCh2qszg UdMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wO9u4EvDoBIegIfL8MLoH5Q9wxbjVMWquYjqBDeWjN4=; b=Nj+l1Vybh4Y4TM79cqwL0PMVyELuQa6JYD6vYhFJUQHhPPYtrfubTNrdH4x1wl+ZaW pMIWLeThRBrx/EM7XL3uS25bBQCEXAas63+8PdM+lbFrfz/I5ShW+5LZNCdr7LK5pMMK AAZOlNAL/26+tH0rotx65OyvxJ4qoBs1v3Lgdd/DVu7dCk1HbJjiG5zZo197dR0OCrFW hEQxwHwbNO1k6oW33+5bXbVZs6kNo9/4TPRKlirZPq+vs3/dxyHvDw5iXUAIpE2v+dZS rV35H42k6lsg299EyROSOfQZcUIqr783bo+TL0ZXP8YJQlaBOKLP3Ip4e+Bv9Tf5jcSe +2Qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b="E8/O5Tlh"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b67si1983741pjc.81.2019.06.19.11.34.05; Wed, 19 Jun 2019 11:34:21 -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; dkim=pass header.i=@android.com header.s=20161025 header.b="E8/O5Tlh"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730080AbfFSScH (ORCPT + 99 others); Wed, 19 Jun 2019 14:32:07 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:37637 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbfFSScG (ORCPT ); Wed, 19 Jun 2019 14:32:06 -0400 Received: by mail-ot1-f66.google.com with SMTP id s20so32824otp.4 for ; Wed, 19 Jun 2019 11:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wO9u4EvDoBIegIfL8MLoH5Q9wxbjVMWquYjqBDeWjN4=; b=E8/O5TlhA1d+ayZUTgQslx4ZiA+Q027+bw2+Xp9uCtbeVn264NHS8BdKeYVAXlPEW2 SNzA3SwsMvflcnUPUChz0KfpziO4Sevl6hSzELWVLn/k/NwLWBLxz0vuVtLjYdiRtj6N A2Pp/YUBu2ZZk2btgrD9dJY8Ag4lLkcohkieR+T5f8qDvyyvG9VL4iuocMjuZRea/MSV /2A90dLrRuM6MT7iYt6+EUsXgzDw0HkDRdsSTsArePyqjfOTEuxn9gdRx1lFSh7+HXC9 vbC3NQGEgAEv4mrM1d6AH/k2s3oqULwuG3anvWRDkWt1uLBuqbroTXWHG3Atwzto6QfG hzYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wO9u4EvDoBIegIfL8MLoH5Q9wxbjVMWquYjqBDeWjN4=; b=JKNEMb9RcWqgomdWRuo3pT4hK4fdqANXJnGjmHaF8+HtZwb0iRWTH3y5oFSWLGGmFI KsI53iPnf+p4psf3X4R6G5YlEFp9Eego6iAMsHhOTNgugSMNp1bj2lfoF+KZQ0/+BVXa 45q2t33C2wUV/jCJLC0VUAzCI4I1iK9haebLyNyEvSEXitOYFFUCgB5zi/AmRIWoAB13 0yAUx3p8mUOYljnTlEfUbh8HwmdIIJ7Ts0emBn3+sf7mP1FOLXPMXUgVf/LB7twDVnry BEuR3/Lo8ZH2oPjJYbTiJ3BOceSY/0LsJwLgytBeEs7idLMOy/zNJmyXwX2QmekI9H2t ECYA== X-Gm-Message-State: APjAAAWRewyrMUQKm8vnYRvPpL5bBg22fD+qeeIL98Cgv8ksyynD5KqO roiPmlCxoqth5Iyr6zGtL4AqmzEisJtvggN1jB+83w== X-Received: by 2002:a9d:7a45:: with SMTP id z5mr1589758otm.197.1560969125109; Wed, 19 Jun 2019 11:32:05 -0700 (PDT) MIME-Version: 1.0 References: <20190618182502.GC203031@google.com> <4587569.x9DSL43cXO@kreacher> <20190619170750.GB10107@kroah.com> In-Reply-To: From: Tri Vo Date: Wed, 19 Jun 2019 11:31:54 -0700 Message-ID: Subject: Re: Alternatives to /sys/kernel/debug/wakeup_sources To: Joel Fernandes Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Sandeep Patil , Viresh Kumar , Hridya Valsaraju , Linux PM , "Cc: Android Kernel" , LKML , Alexei Starovoitov , Steven Rostedt , Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 19, 2019 at 11:01 AM Joel Fernandes wrote: > > On Wed, Jun 19, 2019 at 1:07 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Jun 19, 2019 at 12:53:12PM -0400, Joel Fernandes wrote: > > > > It is conceivable to have a "wakeup_sources" directory under > > > > /sys/power/ and sysfs nodes for all wakeup sources in there. > > > > > > One of the "issues" with this is, now if you have say 100 wake up > > > sources, with 10 entries each, then we're talking about a 1000 sysfs > > > files. Each one has to be opened, and read individually. This adds > > > overhead and it is more convenient to read from a single file. The > > > problem is this single file is not ABI. So the question I guess is, > > > how do we solve this in both an ABI friendly way while keeping the > > > overhead low. > > > > How much overhead? Have you measured it, reading from virtual files is > > fast :) > > I measured, and it is definitely not free. If you create and read a > 1000 files and just return a string back, it can take up to 11-13 > milliseconds (did not lock CPU frequencies, was just looking for > average ball park). This is assuming that the counter reading is just > doing that, and nothing else is being done to return the sysfs data > which is probably not always true in practice. > > Our display pipeline deadline is around 16ms at 60Hz. Conceivably, any > CPU scheduling competion reading sysfs can hurt the deadline. There's > also the question of power - we definitely have spent time in the past > optimizing other virtual files such as /proc/pid/smaps for this reason > where it spent lots of CPU time. > > > And how often does this happen? Does it _need_ to happen? > > These are good questions and we should find out. I am not saying that > sysfs will not work, I am just saying we need to consider all the > things. I will let Tri look into this since he is working on it, I > don't know off the top. There are really two use cases for wakeup_sources in Android: (1) As Sandeep pointed out, it's used to plot history of wakeup sources. This use case might actually be performance sensitive. I'll check with our internal Android teams and loop back here. (2) wakeup_sources information is included in bugreports. Reading/parsing wakeup_sources in this case only happens when generating a bugreport, so not particularly sensitive to overhead.