On Mon, Dec 18, 2017 at 7:26 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 19-12-17, 08:52, Viresh Kumar wrote: >> On 18-12-17, 19:18, Joel Fernandes wrote: >> > Hi Viresh, >> > >> > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar <viresh.ku...@linaro.org> >> > wrote: >> > > On 18-12-17, 12:14, Patrick Bellasi wrote: >> > >> 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
