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

From: Saravana Kannan
Date: Fri Aug 27 2010 - 22:55:47 EST


mark gross wrote:
On Fri, Aug 27, 2010 at 01:10:55AM -0700, skannan@xxxxxxxxxxxxxx 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/