Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1003833ybi; Wed, 19 Jun 2019 11:37:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxwgxhZmAys6rvQeNqlvZAQrO/givA5bG/udz4E02axkKsgyxTy46Gt3KpGvVgXGOtbLuZh X-Received: by 2002:a17:902:7c03:: with SMTP id x3mr96345344pll.242.1560969424370; Wed, 19 Jun 2019 11:37:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560969424; cv=none; d=google.com; s=arc-20160816; b=Ra9V+Z+HYiO9tRYBfbiu0rXRzSgbDdTcKkyoncWKXVkmTYiSyZ7L8astGSE7UNwXHW WoiwIJjZ3afjgGnRuhhelLv50yOP4QlGSd6k2Ksj3z1IbuYW137euwK5e/f6zOLUJoSG 3YsyxrNY/ePkPsHXSwgALuR8Za+Fv8BblTb68svqz1QsVIQ8p6VvcoFovZVsYOlrOXsm aUqbUfhTHHXI3BVdqbShokbBQWQGotH407TP6AUXEBBmhHWjusXzet371c68cZJyb92c ZCffh/r2ZNqqOU3ytojcXr4cl0eY0f2k0MYlkf+jDGrDQvu/oEgkXa+MSw99UKibL4Ip mz1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=fQXb0RX8Mj8al53l9oegXeEyOfglsvCYXaQoqQl5kUM=; b=C0LWNJjwKMixwvpOtHTzqQdGuhDPJ0ILqcS0XqySsLj3J7rn0gCBUMZmx5Fy6m9vaT bCbCP8yZbwFDa5NMzfVD/4iiMS6SKvQIuY7l2v2YRbfzxSgqArhPS/0nHHdK++2XpaOJ dQSds+7vzrPIcljIU1SYwunQgOcvUGh3+l/3Nj3wuallsvTmS8dv9Q4sBdM8LlvVBjoE DyneHSZ7pYxMrrKubtMqWAACIUUgmzFKbkWKHEkKq/+e5Zszx/W8WKRVCVuypGGRaBFB CrmY4T3BTNSyK4gsL4EaHxQrMQkB1RjJTCM2J+5IPbNPO70CTWem51dlK/ipqJwV7BfR a9cQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=02DXmPJF; 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 l24si3656220pgm.248.2019.06.19.11.36.48; Wed, 19 Jun 2019 11:37:04 -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=@kernel.org header.s=default header.b=02DXmPJF; 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 S1726518AbfFSSf0 (ORCPT + 99 others); Wed, 19 Jun 2019 14:35:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:59566 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726175AbfFSSf0 (ORCPT ); Wed, 19 Jun 2019 14:35:26 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 00F55214AF; Wed, 19 Jun 2019 18:35:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560969325; bh=ZSXk5yQY5JgmMnKoJZp5pJgU23ioYLFdLftxt75KSUg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=02DXmPJFYgSNzzsFki+MxmAyHDdHNWPBCaKNAYd4HmV/t2wmOIklt9U7P+VZnV+Rz bcdnh9SjtN/cdTKhJCLgKcpMi8Td9fVE85dyCBm75Kw9cbiFEO1ch+FKsLFoxb0vO+ TpaxZZffvoAfEd4dTfO5JMSWwT2iMvdrbggqfoI0= Date: Wed, 19 Jun 2019 20:35:23 +0200 From: Greg Kroah-Hartman To: Joel Fernandes Cc: "Rafael J. Wysocki" , Tri Vo , "Rafael J. Wysocki" , Sandeep Patil , Viresh Kumar , Hridya Valsaraju , Linux PM , "Cc: Android Kernel" , LKML , Alexei Starovoitov , Steven Rostedt , Alexei Starovoitov Subject: Re: Alternatives to /sys/kernel/debug/wakeup_sources Message-ID: <20190619183523.GA7018@kroah.com> References: <20190618182502.GC203031@google.com> <4587569.x9DSL43cXO@kreacher> <20190619170750.GB10107@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) 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 02:01:36PM -0400, 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. smaps was "odd", but that was done after measurements were actually made to prove it was needed. That hasn't happened yet :) And is there a reason you have to do this every 16ms? > > 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. > > > Parsing files is also hard, and not for sysfs files, you can't have it > > both ways. > > I don't think we are concerned with a parsing issue here, or are > discussing it in this thread. > > > So try it this way, and if there really is a performance issue, we can > > then talk about it... > > Sure that sounds good to me, again I am not saying we should do sysfs. > But we should consider all the issues and chose the right solution. Figure out who needs this, how often it needs it, and how many files really are going to be involved before we try to optimize anything. thanks, greg k-h