[lkml]   [2010]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] pm_qos: Add system bus performance parameter
    On Fri, Aug 27, 2010 at 01:10:55AM -0700, 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
    > >
    > > 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 :(
    > >
    > >
    > > 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.


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