Hi Peter,
On 01/31/2015 10:56 AM, Peter Zijlstra wrote:
On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
So, we do the safe thing only in case of throttling.
No, even for the !throttle aka running tasks. We only use
dl_{runtime,deadline,period} for replenishment, until that time
On 31/01/2015 09:56, Peter Zijlstra wrote:
> On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
>> So, we do the safe thing only in case of throttling.
>
> No, even for the !throttle aka running tasks. We only use
> dl_{runtime,deadline,period} for replenishment, until that time we
>
Hi Peter,
On 01/31/2015 10:56 AM, Peter Zijlstra wrote:
On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
So, we do the safe thing only in case of throttling.
No, even for the !throttle aka running tasks. We only use
dl_{runtime,deadline,period} for replenishment, until that time
On 31/01/2015 09:56, Peter Zijlstra wrote:
On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
So, we do the safe thing only in case of throttling.
No, even for the !throttle aka running tasks. We only use
dl_{runtime,deadline,period} for replenishment, until that time we
observe
On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
> So, we do the safe thing only in case of throttling.
No, even for the !throttle aka running tasks. We only use
dl_{runtime,deadline,period} for replenishment, until that time we
observe the old runtime/deadline set by the previous
On Fri, Jan 30, 2015 at 10:35:02AM +, Juri Lelli wrote:
So, we do the safe thing only in case of throttling.
No, even for the !throttle aka running tasks. We only use
dl_{runtime,deadline,period} for replenishment, until that time we
observe the old runtime/deadline set by the previous
Hi Peter,
On 28/01/2015 14:08, Peter Zijlstra wrote:
> On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
>
>>> >From what I understand we should either modify the tasks run/sleep stats
>>> when we change its parameters or we should schedule a delayed release of
>>> the bandwidth delta
Hi Peter,
On 01/28/2015 03:08 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
>From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it
Hi Peter,
On 28/01/2015 14:08, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it
Hi Peter,
On 01/28/2015 03:08 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it
Hi Peter,
On 01/28/2015 03:08 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
>From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
> >>From what I understand we should either modify the tasks run/sleep stats
> >when we change its parameters or we should schedule a delayed release of
> >the bandwidth delta (when it reaches its 0-lag point, if thats in the
> >future).
Hi Peter,
On 01/28/2015 03:08 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it
On Thu, Jan 15, 2015 at 02:35:46PM +0100, Luca Abeni wrote:
From what I understand we should either modify the tasks run/sleep stats
when we change its parameters or we should schedule a delayed release of
the bandwidth delta (when it reaches its 0-lag point, if thats in the
future).
I
Hi Peter,
On 01/15/2015 01:23 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 12:23:43PM +0100, Luca Abeni wrote:
There are some parts of the patch that I do not understand (for example:
if I understand well, if the task is not throttled you set dl_new to 1...
And if it is throttled you
On Thu, Jan 15, 2015 at 12:23:43PM +0100, Luca Abeni wrote:
> There are some parts of the patch that I do not understand (for example:
> if I understand well, if the task is not throttled you set dl_new to 1...
> And if it is throttled you change its current runtime and scheduling
> deadline...
>
Hi Kirill,
On 01/14/2015 01:43 PM, Kirill Tkhai wrote:
[...]
Say we have a userspace task that evaluates and changes runtime
parameters for other tasks (basically what Luca is doing IIRC), and the
changes keep resetting the sleep time, the whole guarantee system comes
down, rendering the
Hi Kirill,
On 01/14/2015 01:43 PM, Kirill Tkhai wrote:
[...]
Say we have a userspace task that evaluates and changes runtime
parameters for other tasks (basically what Luca is doing IIRC), and the
changes keep resetting the sleep time, the whole guarantee system comes
down, rendering the
On Thu, Jan 15, 2015 at 12:23:43PM +0100, Luca Abeni wrote:
There are some parts of the patch that I do not understand (for example:
if I understand well, if the task is not throttled you set dl_new to 1...
And if it is throttled you change its current runtime and scheduling
deadline...
Hi Peter,
On 01/15/2015 01:23 PM, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 12:23:43PM +0100, Luca Abeni wrote:
There are some parts of the patch that I do not understand (for example:
if I understand well, if the task is not throttled you set dl_new to 1...
And if it is throttled you
13.01.2015, 17:04, "Peter Zijlstra" :
> On Tue, Jan 12, 2015 at 12:26:40PM +0300, Kirill Tkhai wrote:
>>> Well, I'm inclined to agree to Luca's viewpoint. We should not change
>>> parameters of a throttled task or we may affect other tasks.
>> Could you explain your viewpoint more? How does
13.01.2015, 17:04, Peter Zijlstra pet...@infradead.org:
On Tue, Jan 12, 2015 at 12:26:40PM +0300, Kirill Tkhai wrote:
Well, I'm inclined to agree to Luca's viewpoint. We should not change
parameters of a throttled task or we may affect other tasks.
Could you explain your viewpoint more? How
On Tue, Jan 12, 2015 at 12:26:40PM +0300, Kirill Tkhai wrote:
> > Well, I'm inclined to agree to Luca's viewpoint. We should not change
> > parameters of a throttled task or we may affect other tasks.
>
> Could you explain your viewpoint more? How does this affects other tasks?
I agree with Juri
Hi, Juri,
13.01.2015, 11:10, "Juri Lelli" :
> Hi all,
>
> really sorry for the huge delay in replying to this! :(
>
> On 07/01/2015 12:29, Kirill Tkhai wrote:
>> On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
>>> Hi Kirill,
>>>
>>> On Tue, 06 Jan 2015 02:07:21 +0300
>>> Kirill Tkhai
Hi all,
really sorry for the huge delay in replying to this! :(
On 07/01/2015 12:29, Kirill Tkhai wrote:
> On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
>> Hi Kirill,
>>
>> On Tue, 06 Jan 2015 02:07:21 +0300
>> Kirill Tkhai wrote:
>>
>>> On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
Hi all,
really sorry for the huge delay in replying to this! :(
On 07/01/2015 12:29, Kirill Tkhai wrote:
On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
Hi Kirill,
On Tue, 06 Jan 2015 02:07:21 +0300
Kirill Tkhai tk...@yandex.ru wrote:
On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni
On Tue, Jan 12, 2015 at 12:26:40PM +0300, Kirill Tkhai wrote:
Well, I'm inclined to agree to Luca's viewpoint. We should not change
parameters of a throttled task or we may affect other tasks.
Could you explain your viewpoint more? How does this affects other tasks?
I agree with Juri and
Hi, Juri,
13.01.2015, 11:10, Juri Lelli juri.le...@arm.com:
Hi all,
really sorry for the huge delay in replying to this! :(
On 07/01/2015 12:29, Kirill Tkhai wrote:
On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
Hi Kirill,
On Tue, 06 Jan 2015 02:07:21 +0300
Kirill Tkhai
09.01.2015, 14:15, "Luca Abeni" :
> Hi Kirill,
>
> On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
> [...]
If in the future we allow non-privileged users to increase deadline,
we will reflect that in __setparam_dl() too.
>>> Ok.
>> Does my patch help you? It helps me, but anyway I need
Hi Kirill,
On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
[...]
If in the future we allow non-privileged users to increase deadline,
we will reflect that in __setparam_dl() too.
Ok.
Does my patch help you? It helps me, but anyway I need your confirmation.
Sorry about the delay... Anyway, I
09.01.2015, 14:15, Luca Abeni luca.ab...@unitn.it:
Hi Kirill,
On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
[...]
If in the future we allow non-privileged users to increase deadline,
we will reflect that in __setparam_dl() too.
Ok.
Does my patch help you? It helps me, but anyway I need
Hi Kirill,
On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
[...]
If in the future we allow non-privileged users to increase deadline,
we will reflect that in __setparam_dl() too.
Ok.
Does my patch help you? It helps me, but anyway I need your confirmation.
Sorry about the delay... Anyway, I
On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
[...]
and further enqueue_task() places it on the dl_rq.
I was under the impression that no further enqueue_task() will happen (since
the task is throttled, it is not on runqueue, so __sched_setscheduler() will
not dequeue/enqueue it).
But I am
On Ср, 2015-01-07 at 13:45 +0100, Luca Abeni wrote:
> On 01/07/2015 01:29 PM, Kirill Tkhai wrote:
> [...]
> Based on your comments, I suspect my patch can be further
> simplified by moving the call to init_dl_task_timer() in
> __sched_fork().
> >>>
> >>> It seems this way has
On 01/07/2015 01:29 PM, Kirill Tkhai wrote:
[...]
Based on your comments, I suspect my patch can be further
simplified by moving the call to init_dl_task_timer() in
__sched_fork().
It seems this way has problems. The first one is that task may become
throttled again, and we will start dl_timer
On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
> Hi Kirill,
>
> On Tue, 06 Jan 2015 02:07:21 +0300
> Kirill Tkhai wrote:
>
> > On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
> [...]
> > > For reference, I attach the patch I am using locally (based on what
> > > I suggested in my
On Ср, 2015-01-07 at 13:45 +0100, Luca Abeni wrote:
On 01/07/2015 01:29 PM, Kirill Tkhai wrote:
[...]
Based on your comments, I suspect my patch can be further
simplified by moving the call to init_dl_task_timer() in
__sched_fork().
It seems this way has problems. The first one is that
On Ср, 2015-01-07 at 08:01 +0100, Luca Abeni wrote:
Hi Kirill,
On Tue, 06 Jan 2015 02:07:21 +0300
Kirill Tkhai tk...@yandex.ru wrote:
On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
[...]
For reference, I attach the patch I am using locally (based on what
I suggested in my
On 01/07/2015 01:29 PM, Kirill Tkhai wrote:
[...]
Based on your comments, I suspect my patch can be further
simplified by moving the call to init_dl_task_timer() in
__sched_fork().
It seems this way has problems. The first one is that task may become
throttled again, and we will start dl_timer
On 01/07/2015 02:04 PM, Kirill Tkhai wrote:
[...]
and further enqueue_task() places it on the dl_rq.
I was under the impression that no further enqueue_task() will happen (since
the task is throttled, it is not on runqueue, so __sched_setscheduler() will
not dequeue/enqueue it).
But I am
Hi Kirill,
On Tue, 06 Jan 2015 02:07:21 +0300
Kirill Tkhai wrote:
> On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
[...]
> > For reference, I attach the patch I am using locally (based on what
> > I suggested in my previous mail) and seems to work fine here.
> >
> > Based on your
Hi Kirill,
On Tue, 06 Jan 2015 02:07:21 +0300
Kirill Tkhai tk...@yandex.ru wrote:
On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
[...]
For reference, I attach the patch I am using locally (based on what
I suggested in my previous mail) and seems to work fine here.
Based on your
On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
> Hi Kirill,
>
> On 01/04/2015 11:51 PM, Kirill Tkhai wrote:
> > Hi, Luca,
> >
> > I've just notived this.
> [...]
> > I think we should do something like below.
> >
> > hrtimer_init() is already called in sched_fork(), so we shouldn't do this
>
Hi Kirill,
On 01/04/2015 11:51 PM, Kirill Tkhai wrote:
Hi, Luca,
I've just notived this.
[...]
I think we should do something like below.
hrtimer_init() is already called in sched_fork(), so we shouldn't do this
twice. Also, we shouldn't reinit dl_throttled etc if timer is pending,
and we
On Пн, 2015-01-05 at 16:21 +0100, Luca Abeni wrote:
Hi Kirill,
On 01/04/2015 11:51 PM, Kirill Tkhai wrote:
Hi, Luca,
I've just notived this.
[...]
I think we should do something like below.
hrtimer_init() is already called in sched_fork(), so we shouldn't do this
twice. Also, we
Hi Kirill,
On 01/04/2015 11:51 PM, Kirill Tkhai wrote:
Hi, Luca,
I've just notived this.
[...]
I think we should do something like below.
hrtimer_init() is already called in sched_fork(), so we shouldn't do this
twice. Also, we shouldn't reinit dl_throttled etc if timer is pending,
and we
Hi, Luca,
I've just notived this.
30.12.2014, 02:27, "luca abeni" :
> Hi all,
>
> when running some experiments on current git master, I noticed a
> regression respect to version 3.18 of the kernel: when invoking
> sched_setattr() to change the SCHED_DEADLINE parameters of a task that
> is
Hi, Luca,
I've just notived this.
30.12.2014, 02:27, luca abeni luca.ab...@unitn.it:
Hi all,
when running some experiments on current git master, I noticed a
regression respect to version 3.18 of the kernel: when invoking
sched_setattr() to change the SCHED_DEADLINE parameters of a task
48 matches
Mail list logo
