On 04/13/2016 09:07 AM, Rafael J. Wysocki wrote: >>>>> If you want to do remote updates, I guess that will require an >>>>> irq_work to run the update on the target CPU, but then you'll probably >>>>> want to neglect the rate limit on it as well, so it looks like a >>>>> "need_update" flag in struct update_util_data will be useful for that.
Have you added rate limiting at the hook level that I missed? I thought it was just inside schedutil. >>>> >>>> Why is it required to run the update on the target CPU? >>> >>> The fast switching and intel_pstate are the main reason. >>> >>> They both have to write to registers of the target CPU and the code to >>> do that needs to run on that CPU. Ok thanks, I'll take another look at this. I was thinking it might be nice to be able to push the decision on whether to send the IPI in to the governor/hook client. For example in the schedutil case, you don't need to IPI if sugov_should_update_freq() = false (outside the slight chance it might be true when it runs on the target). Beyond that perhaps for policy reasons it's desired to not send the IPI if next_freq <= cur_freq, etc. >> And these two seem to be the only interesting cases for you, because >> if you need to work for the worker thread to schedule to eventually > > s/work/wait/ (sorry) > >> change the CPU frequency for you, that will defeat the whole purpose >> here. I was hoping to submit at some point a patch to change the context for slow path frequency changes to RT or DL context, so this would benefit that case as well. thanks, steve
