On Wed, Jun 06, 2007 at 05:07:33PM +0530, Srivatsa Vaddagiri wrote:
> > I don't think that rt_sched_class :: dequeue_task_rt() is in any of
> > such "fast pathes" that we should really care about an additional
> > math. operation.
> >
> > If this approach is ok, logically-wise (no side effects fro
On Wed, Jun 06, 2007 at 05:07:33PM +0530, Srivatsa Vaddagiri wrote:
> No, fair_sched_class :: put_prev_task() if we are transitioning from
> NORMAL->RT. That will update the fair_clock based on execution time
> of current task in fair_sched class?
On seconds thoughts, this may not be necessary as
On Wed, Jun 06, 2007 at 01:19:01PM +0200, Dmitry Adamushko wrote:
> >Yes this is the approach I prefer, because we burden the fast/normal
> >path less that way (RT->NORMAL transition is not common).
>
> I don't think that rt_sched_class :: dequeue_task_rt() is in any of
> such "fast pathes" that w
On 06/06/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
[ ... ]
> > This way, on RT -> NORMAL transition.. some 'delta_exec' ( between
> > deactivate_task() ---> activate_task() ) will be accounted later as if
> > the task was 'sched_fair_class' during this time.. which I think makes
> > some
On Wed, Jun 06, 2007 at 04:07:01PM +0530, Balbir Singh wrote:
> Dmitry Adamushko wrote:
> > On 06/06/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> >> On Wed, Jun 06, 2007 at 09:01:43AM +0200, Ingo Molnar wrote:
> >> > [...] and my tree already contains the fixes for rt task's
> >> > exec_star
Dmitry Adamushko wrote:
> On 06/06/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>> On Wed, Jun 06, 2007 at 09:01:43AM +0200, Ingo Molnar wrote:
>> > [...] and my tree already contains the fixes for rt task's
>> > exec_start.
>>
>> Can I have this snapshot pls? I have to deal with the same issu
On 06/06/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Wed, Jun 06, 2007 at 09:01:43AM +0200, Ingo Molnar wrote:
> [...] and my tree already contains the fixes for rt task's
> exec_start.
Can I have this snapshot pls? I have to deal with the same issue when
the current task switches group
On Wed, Jun 06, 2007 at 09:01:43AM +0200, Ingo Molnar wrote:
> [...] and my tree already contains the fixes for rt task's
> exec_start.
Can I have this snapshot pls? I have to deal with the same issue when
the current task switches groups and I was planning to fix it by
introducing a set_curr_t
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > i'm pleased to announce release -v15 of the CFS scheduler patchset.
>
> Do I smell a bug when a task switches its scheduling classes?
>
> Lets say a task was in real-time class for a long time and switches to
> fair-sched class. When update_c
On Thu, May 31, 2007 at 05:09:08PM +0200, Ingo Molnar wrote:
> i'm pleased to announce release -v15 of the CFS scheduler patchset.
Do I smell a bug when a task switches its scheduling classes?
Lets say a task was in real-time class for a long time and switches to
fair-sched class. When update_cur
i'm pleased to announce release -v15 of the CFS scheduler patchset.
The CFS rolled-up patch against v2.6.22-rc3, v2.6.22-rc3-mm1,
v2.6.21.1/3 or v2.6.20.10 can be downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
-v15 includes smaller fixes only. More precise
11 matches
Mail list logo