Re: [PATCH] pm_qos: Add system bus performance parameter

[skannan@codeaurora.org]

> 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.