On Wed, Jun 01, 2016 at 04:16:12PM +0530, Viresh Kumar wrote:

On 31-05-16, 18:08, Steve Muckle wrote:

quoted

Checking the table type

I hope you are talking about my patch here and in that case its not
table-type, but relation-type.

I was referring to Rafael's comment about having the core check how the
table was sorted and process it accordingly. It doesn't apply to the
approach in your patches.

quoted

and performing the associated lookup seems
workable to me though it adds a bit of complexity.

Also what about leaving it as is?

So, your series kind of just triggered this thing, but freq matching
should always be really fast. And I feel that we should attempt to
making it fast.

I agree with that goal.

quoted

I didn't fully catch the concern with
abuse in the series I posted, and it pushes this complexity of dealing
with the freq table efficiently down into the driver, which is best
suited for that IMO.

Not really. Its a single driver today, it will be 20 drivers tomorrow.
We really want to do such common stuff in core whenever it is
possible.

quoted

Another thought is that it'd be nice to eventually reduce
cpufreq_driver_{fast_switch,resolve_freq} into simple inline functions
so that we could jump to the driver directly from schedutil, eliminating
a function call.

That's kind of orthogonal to this :)

Handling freq table walking exclusively in cpufreq core will add to the
size of stuff to be inlined in schedutil to avoid extra function calls.	

thanks,
Steve