[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190626011221.GB22454@kroah.com>
Date: Wed, 26 Jun 2019 09:12:21 +0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Tri Vo <trong@...roid.com>
Cc: rjw@...ysocki.net, viresh.kumar@...aro.org, rafael@...nel.org,
hridya@...gle.com, sspatil@...gle.com,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
kernel-team@...roid.com--annotate
Subject: Re: [PATCH] PM / wakeup: show wakeup sources stats in sysfs
On Tue, Jun 25, 2019 at 05:54:49PM -0700, Tri Vo wrote:
> Userspace can use wakeup_sources debugfs node to plot history of suspend
> blocking wakeup sources over device's boot cycle. This information can
> then be used (1) for power-specific bug reporting and (2) towards
> attributing battery consumption to specific processes over a period of
> time.
>
> However, debugfs doesn't have stable ABI. For this reason, expose wakeup
> sources statistics in sysfs under /sys/power/wakeup_sources/<name>/
>
> Add following attributes to each wakeup source. These attributes match
> the columns of /sys/kernel/debug/wakeup_sources.
>
> active_count
> event_count
> wakeup_count
> expire_count
> active_time (named "active_since" in debugfs)
> total_time
> max_time
> last_change
> prevent_suspend_time
Can you also add a Documentation/ABI/ update for your new sysfs files so
that we can properly review this?
> Embedding a struct kobject into struct wakeup_source changes lifetime
> requirements on the latter. To that end, change deallocation of struct
> wakeup_source using kfree to kobject_put().
Ick, are you sure you need a new kobject here? Why wouldn't a named
attribute group work instead? That should keep this patch much smaller
and simpler.
> +static ssize_t wakeup_source_count_show(struct wakeup_source *ws,
> + struct wakeup_source_attribute *attr,
> + char *buf)
> +{
> + unsigned long flags;
> + unsigned long var;
> +
> + spin_lock_irqsave(&ws->lock, flags);
> + if (strcmp(attr->attr.name, "active_count") == 0)
> + var = ws->active_count;
> + else if (strcmp(attr->attr.name, "event_count") == 0)
> + var = ws->event_count;
> + else if (strcmp(attr->attr.name, "wakeup_count") == 0)
> + var = ws->wakeup_count;
> + else
> + var = ws->expire_count;
> + spin_unlock_irqrestore(&ws->lock, flags);
> +
> + return sprintf(buf, "%lu\n", var);
> +}
Why is this lock always needed to be grabbed? You are just reading a
value, who cares if it changes inbetween reading it and returning the
buffer string as it can change at that point in time anyway?
thanks,
greg k-h
Powered by blists - more mailing lists