On 06-Mar 09:35, Steven Rostedt wrote:
> On Thu, 2 Mar 2017 15:45:03 +
> Patrick Bellasi wrote:
>
> > @@ -287,6 +289,10 @@ static void sugov_update_shared(struct
> > update_util_data *hook, u64 time,
> > goto done;
> > }
> >
> > + /* Skip updates generated by sugov kthr
On Thu, 2 Mar 2017 15:45:03 +
Patrick Bellasi wrote:
> @@ -287,6 +289,10 @@ static void sugov_update_shared(struct update_util_data
> *hook, u64 time,
> goto done;
> }
>
> + /* Skip updates generated by sugov kthreads */
> + if (curr == sg_policy->thread)
I t
On 03-03-17, 12:12, Patrick Bellasi wrote:
> On 03-Mar 10:49, Viresh Kumar wrote:
> > I always wanted to avoid such hacks when I moved to the RT thread :(
>
> Indeed, it is a bit of an hack... but still it's true that this is a
> "special" RT thread which must not bias OPP selection.
I agree. We
On 03-Mar 10:49, Viresh Kumar wrote:
> On 02-03-17, 15:45, Patrick Bellasi wrote:
> > In system where multiple CPUs shares the same frequency domain a small
> > workload on a CPU can still be subject frequency spikes, generated by
> > the activation of the sugov's kthread.
> >
> > Since the sugov
On 02-03-17, 15:45, Patrick Bellasi wrote:
> In system where multiple CPUs shares the same frequency domain a small
> workload on a CPU can still be subject frequency spikes, generated by
> the activation of the sugov's kthread.
>
> Since the sugov kthread is a special RT task, which goal is just
In system where multiple CPUs shares the same frequency domain a small
workload on a CPU can still be subject frequency spikes, generated by
the activation of the sugov's kthread.
Since the sugov kthread is a special RT task, which goal is just that to
activate a frequency transition, it does not
6 matches
Mail list logo
