On Wed, Jun 01, 2016 at 04:16:12PM +0530, Viresh Kumar wrote:
On 31-05-16, 18:08, Steve Muckle wrote:
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.
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.
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.
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