Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Rafael J. Wysocki" <rjw@xxxxxxx> writes:

> On Thursday, March 08, 2012, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@xxxxxxx> writes:
>> 
>> > From: Rafael J. Wysocki <rjw@xxxxxxx>
>> >
>> > A runtime suspend of a device (e.g. an MMC controller) belonging to
>> > a power domain or, in a more complicated scenario, a runtime suspend
>> > of another device in the same power domain, may cause power to be
>> > removed from the entire domain.  In that case, the amount of time
>> > necessary to runtime-resume the given device (e.g. the MMC
>> > controller) is often substantially greater than the time needed to
>> > run its driver's runtime resume callback.  That may hurt performance
>> > in some situations, because user data may need to wait for the
>> > device to become operational, so we should make it possible to
>> > prevent that from happening.
>> >
>> > For this reason, introduce a new sysfs attribute for devices,
>> > power/pm_qos_latency_us, allowing user space to specify the upper
>> 
>> If we're expecting to have more of these knobs, maybe having a pm_qos
>> subdir under power will keep down the clutter in /sys/devices/.../power.
>> This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us.
>
> I'm not sure how difficult it is to create a subdir in sysfs under something
> that is not a kobject.
>
> Besides, this follows the convention already used by wakeup and runtime PM
> attributes that don't have their own subdirs (although there may be a number
> of them in each category).

OK

>> I think 'latency' alone is a bit too vague (wakeup latency?  interrupt
>> latency?  I think wakeup latency is clearer.  Another possibility is
>> resume latency, IMO, that will lead to confusion about whether this
>> field also affects system suspend/resume.
>
> I think "wakeup latency" will lead to more confusion because of the
> wakeup-related attributes.  

What confusion?  All of those are related to device wakeups from some
low power state, and so is this proposed latency attribute.  So I don't
understand the potential confusion.

> I'll go for "resume_latency" if you don't mind. :-)

Most people think of resume as coming back from system PM.  If this is
called resume_latency, I would expect confusion about why setting this
attribute has no effect on how fast their system returns from system
suspend.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux