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
    On Fri, Aug 27, 2010 at 01:10:55AM -0700, skannan@codeaurora.org wrote:
    >
    > > 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.

    well then current pm_qos code for network throughput takes the max.

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

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

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

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

    --mark



    \
     
     \ /
      Last update: 2010-08-28 04:09    [W:0.030 / U:93.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site