Thread (42 messages) 42 messages, 7 authors, 2017-12-20

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

From: Joel Fernandes <hidden>
Date: 2017-12-19 03:30:07
Also in: lkml

On Mon, Dec 18, 2017 at 7:26 PM, Viresh Kumar [off-list ref] wrote:
On 19-12-17, 08:52, Viresh Kumar wrote:
quoted
On 18-12-17, 19:18, Joel Fernandes wrote:
quoted
Hi Viresh,

On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar [off-list ref] wrote:
quoted
On 18-12-17, 12:14, Patrick Bellasi wrote:
quoted
For example, swithing from:

 - void (*func)(struct update_util_data *data, u64 time,
 -              unsigned int flags))
 + void (*func)(struct update_util_data *data, u64 time,
 +              unsigned int flags, bool set))

Where the additional boolean is actually used to define which
operation we wanna perform on the flags?
The code will eventually have the same complexity or ugliness in both
the cases. I would like to start with another flag for now and see if
people prefer another parameter.
Though I think that will solve Rafael's concern of polluting the flags
for something schedutil specific. I also feel adding extra callback
parameter is cleaner than 2 new clear flags.
Okay, I will then wait for Rafael to come online and comment on what
he would prefer before posting.
I thought about it once more. If we decide eventually to add another
parameter, then why isn't the approach that this patch takes better
than that? i.e. Use the 31st bit of flags for clear bit ? We can
remove setting/clearing flags for CFS, that's it.
Yes that's clean to me but then as Rafael said, the use of this flag
will be too specific for schedutil-only sg_cpu->flags clearing purpose
right?

If adding the single flag is OK in the grand cpufreq scheme of things,
then that's fine with me.

Thanks,

- Joel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help