On Wed, Aug 3, 2011 at 7:02 AM, Kevin Hilman <khilman@xxxxxx> wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> writes: > >> On Friday, July 15, 2011, MyungJoo Ham wrote: >>> For a usage example, please look at >>> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/devfreq >>> >>> In the above git tree, DVFS (dynamic voltage and frequency scaling) mechanism >>> is applied to the memory bus of Exynos4210 for Exynos4210-NURI boards. >>> In the example, the LPDDR2 DRAM frequency changes between 133, 266, and 400MHz >>> and other related clocks simply follow the determined DDR RAM clock. >>> >>> The DEVFREQ driver for Exynos4210 memory bus is at >>> /arch/arm/mach-exynos4/devfreq_bus.c in the git tree. >>> >>> MyungJoo Ham (3): >>> PM: Introduce DEVFREQ: generic DVFS framework with device-specific >>> OPPs >>> PM / DEVFREQ: add example governors >>> PM / DEVFREQ: add sysfs interface (including user tickling) >> >> OK, I'm going to take the patches for 3.2. > > Sorry for being late to the discussion, but personally I don't think > this should be merged for v3.2. > > First, I think the governor part of this series is basically fine, and > can see some cases where it would be useful, but as Mike has pointed > out, there is still a majority of devices for which a governor like this > would be overkill. > > My main problem is with the QoS aspects. There is significant overlap > between this approach and the per-device PM QoS approach currently being > proposed by Jean Pihet, and I think any sort of per-device DVFS should > be built on top of a more generic per-device QoS layer (such as Jean's.) Then, what about adding a governor? Besides, DEVFREQ is designed to allow each device to create its own governors. The governors in the devfreq.c are meant to be used commonly by "many" devices. For PM QoS, we may have several approaches: 1. Adding a governor aware of PM QoS taking PM QoS parameters. 2. Modifying OPP to be aware of PM QoS so that only OPPs meeting the requirement are enabled if the PM QoS requirement specifies frequency or voltage conditions explicitly. 3. Modifying DEVFREQ to be aware of PM QoS and let DEVFREQ ignore frequencies that do not satisfy the PM QoS requirement. As in approach 2, the requirement also needs to be explicit about frequency / voltage conditions or we need to interpret devfreq_dev_status result in terms of PM QoS. > > This series currently provides a *very* basic QoS mechanism (e.g. fixed > duration frequency constraint) in the form of "tickle", which BTW I seem > to having a hard time understanding (more on that below...) > > More importantly though, this series also introduces a sysfs layer for > doing its QoS-like stuff, so adding this and then adding a more generic > per-device QoS is asking for confusion about how userspace is to do QoS. > And adding a sysfs interface may be turn out to be difficult to remove. > > Basically, without a more general constraints mechanism in place, I > don't see how this can be generally useful since there are too many > assumptions made with the current "tickle" approach, and as Mike has > pointed out, it cannot cleanly handle cases where there might be > multiple DVFS-related constraints on a given device. > > OK, back to "tickle"... I haven't yet fully understood how that > interface is intended to be used, or who the potential users might be > and it is not documented in the code or changelog. I also didn't see > any users of that API (except the sysfs code.) > > IIUC, tickle is just basically a way to set a frequency constraint on a > device for a fixed duration. However, if tickle has been requested, any > OPP change will also force a change to the highest performance OPP > temporarily before changing to the target OPP. > > Maybe I'm not understanding the usage of it fully, but that seems like > hard-coding policy into the framework that might not be appropriate. > For example, what if there are other devices with constraints such that > they cannot currently scale frequency/voltage? > > Mabye MyungJoo can explain in more detail the usecases for tickle? Tickle is not for QoS between devices. It is for faster reaction to (human) user inputs at DVFS side where waiting for DVFS's reaction takes too much time and reducing polling interval costs too much. In fact, this tickling method was quite effective with CPUFREQ's ondemand governor (not upstreamed). We may tune DVFS constants to let it react faster with lower threshold; however, this results in higher power consumption with small load. Here goes more detailed description about the issue intended to be tackled by tickling, the response time of GUI. With DVFS (CPUFREQ), we have been suffering from slower user response time (e.g., dragging touch screen of mobile devices at "application drawer" or "web browsers"). Let's assume a system with a CPU that runs at the range of 100MHz ~ 2GHz and a GUI that requires at least1.5GHz for smooth transitions. If we are going to use 60Hz based display and 20ms CPUFREQ polling interval, a sudden user input requires 30ms of delay in average to get CPU to work at high speed, which loses 2 frames (often, it takes more time/frames for CPUFREQ to react; I don't know why). If a user repeatedly drags and stops the touch screen, such delay and lost frames become very noticeable and the screen follows user's finger retarded. With CPUFREQ-ondemand, tickling has been made such test to have almost same result with that of "performance" governor. For the sysfs interface... we actually do not need sysfs interface for tickling if we are going to allow tickle function to the interrupt handler of HCI devices (touch screen, keyboards, mice, ...). However, it seems that many people don't like that idea; thus, I thought I need to allow userspace user-input handlers to tickle. > > Thanks, > > Kevin > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
