On Mon, Oct 14, 2013 at 9:08 PM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > Tomasz, > > On Fri, Oct 11, 2013 at 7:06 PM, Tomasz Figa <t.figa@xxxxxxxxxxx> wrote: >> Well, it's some kind of difference indeed. However, how often can >> a frequency transition happen? >> >> I believe that ondemand allows minimum sampling period of >> 100 * transition latency, so even without considering the PLL lock time, >> we would have at most a single delay of ~400 us every ~40 ms, during >> which remaining CPUs are operating normally, because of switching to >> MPLL temporarily. >> >> A bit more interesting case would be the Android interactive governor, >> which scales up the CPU on any wake-up event, but I don't believe any >> user would notice the extra 17,5 us from touching the screen to seeing >> a menu animation, for example. > > OK. You've clearly looked at this more than I. :) I was merely > recalling conversations that others had over a year ago and > remembering some of our engineers being concerned about latencies even > at this level, but I'm not sure if they had hard data. I added Sonny > to see if he might remember more, though I don't think he was the one > pushing for optimizations in the past. > > > Note that we actually are using the Interactive governor in our > systems, and it is the interactive "time to spin up on user input" > that I'm most worried about. ...but you're right that I think the > user perceivable values are in the 10s of milliseconds and not in the > 10s of microseconds. Yeah, we're using interactive, and we're typically running on the slowest clock frequency when a user uses an input device that causes a boost to happen, and I think the initial measurements (last year) of how long it took to complete just the voltage transition on Snow were something like 1 millisecond mostly because of how udelay worked by using a fixed number of loops. That seemed pretty long but wasn't considered terrible because after we got up to a higher speed it wouldn't take as long to make further transitions, and I also didn't expect us to make that transition often enough that it would be a significant impact on CPU usage, and 1ms probably isn't quite enough for a user to notice. > > >> Please correct me if I'm missing something here. >> >>> Anyway, when it's something as simple as passing in a parameter to get >>> it right, it seems worth doing. >> >> Sure, any patches improving things are welcome, I was just wondering >> whether the improvement will be of any significance. Looking forward >> to respective patches, hoping that they will not complicate the code >> too much (although we already have a struct for PLL parameters, so they >> should not). > > I'd still love to see the change land that allows this to be right. > 17.5us may not matter much, but with the PLL parameter struct it > should be pretty easy / clean. ...and it also allows us to map the > number back the user manual, which can make it easier to understand > (there's currently nothing documenting why the number is 270, not 250 > or 200). > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |