> nack. > > Change the name to system_bus_throughput_pm_qos assuming KBS units and > I'll ok it. It needs to be portable and without units I think drivers > will start using magic numbers that will break when you go from a > devices with 16 to 32 bus with the same clock. > > We had an email thread about this last year > http://lkml.org/lkml/2009/12/31/143 > I don't recall solution ever coming out of it. I think you guys didn't > like the idea of using units. Further I did post a patch adding > something like using units. Although I looks like I botch the post the > linux-pm as I can't seem to find it in the linux-pm archives :( > http://lkml.org/lkml/2010/4/22/213 > > Would you be ok with using throughput instead of a unit less performance > magic number? > > > --mark Ignoring other details for now, the biggest problem with throughput/KBps units is that PM QoS can't handle it well in its current state. For KBps the requests should be added together before it's "enforced". Just picking the maximum won't work optimally. Another problem with using KBps is that the available throughput is going to vary depending on the CPU frequency since the CPU running at a higher freq is going to use more bandwidth/throughput than the same CPU running at a lower freq. A KHz unit will side step both problems. It's not the most ideal in theory but it's simple and gets the job done since, in our case, there aren't very many fine grained levels of system bus frequencies (and corresponding throughputs). I understand that other architectures might have different practical constraints and abilities and I didn't want to impose the KHz limitation on them. That's the reason I proposed a parameter whose units is defined by the "enforcer". Thoughts? Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
