On 14-11-16, 10:22, Peter Zijlstra wrote:
> Any static prio value is wrong (static prio assignment requires system
> knowledge that the kernel doesn't and cannot have), 50 is what threaded
> IRQs default too as well IIRC, so it would at least be consistent with
> that.
Yes you are correct and I ha
On Sat, Nov 12, 2016 at 10:52:35AM +0530, Viresh Kumar wrote:
> On 11 November 2016 at 20:09, Peter Zijlstra wrote:
> > On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote:
> >> >+struct sched_param param = { .sched_priority = 50 };
> >>
> >> won't you have a tunable here? (sysct
On 13-11-16, 23:44, Rafael J. Wysocki wrote:
> To a minimum, there should be a comment regarding that in the patches.
Wanted to get the comment written properly before sending that in the patch. Can
you please rectify this based on what you are looking for ?
diff --git a/kernel/sched/cpufreq_sche
On 12-11-16, 10:57, Viresh Kumar wrote:
> On 12 November 2016 at 07:01, Saravana Kannan wrote:
> > Hold on a sec. I thought during LPC someone (Peter?) made a point that when
> > RT thread run, we should bump the frequency to max?
>
> I wasn't there but AFAIU, this is the case we have currently f
On Sun, Nov 13, 2016 at 8:47 PM, Steve Muckle wrote:
> On Sun, Nov 13, 2016 at 03:37:18PM +0100, Rafael J. Wysocki wrote:
>> > Hold on a sec. I thought during LPC someone (Peter?) made a point that when
>> > RT thread run, we should bump the frequency to max? So, schedutil is going
>> > to trigger
On Fri, Nov 11, 2016 at 11:16:59PM +0100, Rafael J. Wysocki wrote:
> > + struct sched_param param = { .sched_priority = 50 };
>
> I'd define a symbol for the 50. It's just one extra line of code ...
A minor point for sure, but in general what's the motivation for
defining symbols for thing
On Sun, Nov 13, 2016 at 03:37:18PM +0100, Rafael J. Wysocki wrote:
> > Hold on a sec. I thought during LPC someone (Peter?) made a point that when
> > RT thread run, we should bump the frequency to max? So, schedutil is going
> > to trigger schedutil to bump up the frequency to max, right?
>
> No,
On Sat, Nov 12, 2016 at 2:31 AM, Saravana Kannan wrote:
> On 11/11/2016 02:16 PM, Rafael J. Wysocki wrote:
>>
>> On Fri, Nov 11, 2016 at 11:22 AM, Viresh Kumar
>> wrote:
>>>
>>> If slow path frequency changes are conducted in a SCHED_OTHER context
>>> then they may be delayed for some amount of t
On 12 November 2016 at 07:01, Saravana Kannan wrote:
> Hold on a sec. I thought during LPC someone (Peter?) made a point that when
> RT thread run, we should bump the frequency to max?
I wasn't there but AFAIU, this is the case we have currently for the schedutil
governor. And we (mobile world, L
On 12 November 2016 at 03:46, Rafael J. Wysocki wrote:
>> +static void sugov_work(struct kthread_work *work)
>> {
>> - struct sugov_policy *sg_policy = container_of(work, struct
>> sugov_policy, work);
>> + struct sugov_policy *sg_policy =
>> + container_of(work, struc
On 11 November 2016 at 20:09, Peter Zijlstra wrote:
> On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote:
>> >+struct sched_param param = { .sched_priority = 50 };
>>
>> won't you have a tunable here? (sysctl?)
>
> You can use the regular userspace tools, like schedtool and chrt
On 11 November 2016 at 20:02, Tommaso Cucinotta
wrote:
> would you have an insight, as to what runtime/deadline/period to set, and/or
> what specific timing constraints you'd like to set, just for this cpufreq
> slowpath work?
I don't have any such figures for not at least :(
On 11/11/2016 02:16 PM, Rafael J. Wysocki wrote:
On Fri, Nov 11, 2016 at 11:22 AM, Viresh Kumar wrote:
If slow path frequency changes are conducted in a SCHED_OTHER context
then they may be delayed for some amount of time, including
indefinitely, when real time or deadline activity is taking pl
On Fri, Nov 11, 2016 at 11:22 AM, Viresh Kumar wrote:
> If slow path frequency changes are conducted in a SCHED_OTHER context
> then they may be delayed for some amount of time, including
> indefinitely, when real time or deadline activity is taking place.
>
> Move the slow path to a real time ker
On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote:
> >+struct sched_param param = { .sched_priority = 50 };
>
> won't you have a tunable here? (sysctl?)
You can use the regular userspace tools, like schedtool and chrt to set
priorities.
Hi,
On 11/11/2016 11:22, Viresh Kumar wrote:
If slow path frequency changes are conducted in a SCHED_OTHER context
then they may be delayed for some amount of time, including
indefinitely, when real time or deadline activity is taking place.
Move the slow path to a real time kernel thread. In t
If slow path frequency changes are conducted in a SCHED_OTHER context
then they may be delayed for some amount of time, including
indefinitely, when real time or deadline activity is taking place.
Move the slow path to a real time kernel thread. In the future the
thread should be made SCHED_DEADLI
17 matches
Mail list logo
