linux-kernel - Re: [PATCH] pm_qos: Add system bus performance parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100828020540.GB8341@gvim.org>
Date:	Fri, 27 Aug 2010 19:05:40 -0700
From:	mark gross <markgross@...gnar.org>
To:	skannan@...eaurora.org
Cc:	markgross@...gnar.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	James Bottomley <james.bottomley@...e.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jonathan Corbet <corbet@....net>, khilman@...prootsystems.com
Subject: Re: [PATCH] pm_qos: Add system bus performance parameter

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/