[ trimmed the cc' list ]
On 17/12/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> On Mon, 17 Dec 2007, Dmitry Adamushko wrote:
>
> >
> > It may be related, maybe not. One 'abnormal' thing (at least, it
> > occurs only once in this log. Should be
pon scheduling _in_, and it's of RT
type (prio: 49 and schedule() --> put_prev_task_rt()) upon scheduling
_out_.
Unless you run some modified version of 'hackbench', it doesn't chenge
scheduling classes... so maybe a lifted prio is a consequence of
ome paths that might explain crashes you have been observing?
I haven't analyzed this case for -rt, so I'm just throwing in the idea in case
it can be useful.
---
From: Dmitry Adamushko <[EMAIL PROTECTED]>
sched: introduce t
On 16/12/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
>
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -7360,7 +7360,7 @@ void sched_move_task(struct task_struct *tsk)
> >
> >
)
update_rq_clock(rq);
- running = task_running(rq, tsk);
+ running = (rq->curr == tsk);
on_rq = tsk->se.on_rq;
if (on_rq) {
---
--
Best regards,
Dmitry Adamushko
diff --git a/include/linux/sched.h b/include/linux/sched.h
diff --git a/kernel/sched.c b/kernel/sched.c
index d
On 15/12/2007, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
>
> My analysis was flawed (hmm... me was under control of Belgium beer :-)
>
ok, I've got another one (just in case... well, this late hour to be
blamed now :-/)
according to Dhaval, we have a crash on ia64 (it
On 15/12/2007, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 15, 2007 at 11:22:08AM +0100, Dmitry Adamushko wrote:
> > On 14/12/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 14 Dec 2007, Dmitry Adamushko wrote:
> > >
&
On 14/12/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 14 Dec 2007, Dmitry Adamushko wrote:
>
> >
> > argh... it's a consequence of the 'current is not kept within the tree"
> > indeed.
> >
>
> Thanks Dmitry for trac
sk()'... it makes the interface less transparent
indeed.
/me thinking on how to get it fixed (e.g. set_task_cfs_rq() might take
care of it) or just get this special-case issue removed (have to check
whether we lose anything in this case)... sigh.
--
Best regards,
Dmitry Adamushko
ouldn't be situations
leading to some sort of de-synchronization in determining the real
'current'.
Will look at it closer.
>
> --
> regards,
> Dhaval
>
--
Best regards,
Dmitry Adamushko
___
Containers
01 ./batech-test.sh
hang?
just to be sure SMP does matter here (most likely yes, I guess).
TIA,
>
> Thanks,
> -Kame
>
--
Best regards,
Dmitry Adamushko
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/
, cfs_rq->curr can be NULL
> for the child.
Would it be better, logically-wise, to use is_same_group() instead?
Although, we can't have 2 groups with cfs_rq->curr != NULL on the same
CPU... so if the child belongs to another group, it's cfs_rq->curr is
auto
;running?' tests to be separate.
Humm... the 'current' is not kept within the tree but
current->se.on_rq is supposed to be '1' ,
so the old code looks ok to me (at least for the 'leaf' elements).
Maybe you were able to get more useful oops on your site?
> --
se->load.weight = shares;
> + se->load.inv_weight = div64_64((1ULL<<32), shares);
A bit of nit-picking... are you sure, there is no need in non '__'
versions of dequeue/enqueu() here (at least, for the sake of
update_curr())? Although, I don't have -mm at hand at
enqueue_task(rq, tsk, 0);
if (unlikely(running) && tsk->sched_class == &fair_sched_class)
tsk->sched_class->set_curr_task(rq);
}
task_rq_unlock(rq, &flags);
}
> --
> Regards,
> vatsa
>
--
Best
extra typing is worth it ;)
>
> Ok! Here's the modified patch (against 2.6.23-rc4-mm1).
as everyone seems to be in a quest for a better name... I think, the
obvious one would be just 'group_sched'.
--
Best regards,
Dmitry Adamushko
__
ask_cfs_rq(tsk);
> +
> + if (on_rq)
> +activate_task(rq, tsk, 0);
> +
> + if (unlikely(rq->curr == tsk) && tsk->sched_class ==
> &fair_sched_class)
> + tsk->sched_class->set_curr_task(rq);
> +
> +
t say, user's task becomes finally active after _a lot_ of inactive
ticks (the user came back).. now it's in the rq and waiting for its
turn (which can be easily > 1 tick).. in the mean time 'load
balancing' is triggered.. and it consider
On 12/06/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Tue, Jun 12, 2007 at 11:03:36AM +0200, Dmitry Adamushko wrote:
> I had an idea of per-sched-class 'load balance' calculator. So that
> update_load() (as in your patch) would look smth like :
>
> ...
internally in update_load_fair()) ... but again, I'll come up with
some code for further discussion.
--
Regards,
vatsa
--
Best regards,
Dmitry Adamushko
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/lis
20 matches
Mail list logo
