lkml.org 
[lkml]   [2010]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] pm_qos: Add system bus performance parameter
mark gross wrote:
> On Fri, Aug 27, 2010 at 01:10:55AM -0700, skannan@codeaurora.org wrote:
>> 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.
>
> well then current pm_qos code for network throughput takes the max.

I don't know how the network throughput is enforced, but if the unit is
KBps and it's just doing a Max, then I think it's broken. If two clients
request 50 KBps and your network can go till 200 KBps, you would still
be requesting 50 KBps when you could have requested 100 KBps.

Any specific reason PM QoS doesn't support a "summation" "comparitor"?

>> 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.
>
> um, if your modem SPI needs a min freq its really saying it needs a min
> throughput (throughput is just a scaler times freq, and 8KBS is a 13 bit
> shift away from HZ for SPI)

I think my point wasn't clear. Say the driver is doing mem read/write
and it needs 10 MBps and the system bus maxes out at 20 MBps.

When the CPU is idling, and isn't using the system bus, it would be
sufficient for the system bus to run at 10MBps speeds. But when CPU
starts executing at full speed, it's going to eat up some bandwidth and
the system bus will have to operate at 15 or 20 MBps speeds.

>> 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 think your getting too wrapped up with this Hz thing and need write a
> couple of shift macros to convert between Kbs and Hz and be happy.

Yes, I could just do this and call it a day. Although, in my opinon,
it's a misrepresentation of the parameter since we aren't doing a
summation of the requests.

>> 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".
>
> The problem is that doing this will result in too many one-off drivers
> that don't port nicely to my architecture when I use the same
> peripheral as you.

Most of the drivers/devices that really need PM QoS and don't degrade
gracefully are internal to SoCs. I can't think of too many external or
loosely coupled devices that don't degrade gracefully. Anyway,
theoritically, your point is valid.

>> Thoughts?
>>
> not really anything additional, other than I wonder why kbs isn't
> working for you. Perhaps I'm missing something subtle.

I don't think that PM QoS in it's current state can meet all the real
requirements of bus bandwidth configuration or management. Which is fine
-- we need to start somewhere. Something like what Kevin mentions or a
different method would be needed to get this right for the complex
cases. I too would be very eager to join this discussion in one of the
conferences (Linux Plumbers?).

My thought was that till that's ready (this has been in discussion for
_at least_ 8 months) we could go with a PM QoS parameter (preferably
without units) and switch to the new design when it's available. I would
be more than glad to switch to the new/future design when it's available.

Did I convince you to allow a unit less parameter? :-)

-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


\
 
 \ /
  Last update: 2010-08-28 04:57    [W:0.178 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site