From: Dmitry Adamushko <dmitry.adamushko@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mike Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org
Subject: Re: [git] CFS-devel, latest code
Date: Tue, 25 Sep 2007 23:35:27 +0200 [thread overview]
Message-ID: <1190756127.18744.23.camel@earth> (raw)
humm... I think, it'd be safer to have something like the following
change in place.
The thing is that __pick_next_entity() must never be called when
first_fair(cfs_rq) == NULL. It wouldn't be a problem, should 'run_node'
be the very first field of 'struct sched_entity' (and it's the second).
The 'nr_running != 0' check is _not_ enough, due to the fact that
'current' is not within the tree. Generic paths are ok (e.g. schedule()
as put_prev_task() is called previously)... I'm more worried about e.g.
migration_call() -> CPU_DEAD_FROZEN -> migrate_dead_tasks()... if
'current' == rq->idle, no problems.. if it's one of the SCHED_NORMAL
tasks (or imagine, some other use-cases in the future -- i.e. we should
not make outer world dependent on internal details of sched_fair class)
-- it may be "Houston, we've got a problem" case.
it's +16 bytes to the ".text". Another variant is to make 'run_node' the
first data member of 'struct sched_entity' but an additional check (se !
= NULL) is still needed in pick_next_entity().
what do you think?
---
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index dae714a..33b2376 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -563,9 +563,12 @@ set_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq)
{
- struct sched_entity *se = __pick_next_entity(cfs_rq);
-
- set_next_entity(cfs_rq, se);
+ struct sched_entity *se = NULL;
+
+ if (first_fair(cfs_rq)) {
+ se = __pick_next_entity(cfs_rq);
+ set_next_entity(cfs_rq, se);
+ }
return se;
}
---
next reply other threads:[~2007-09-25 21:35 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 21:35 Dmitry Adamushko [this message]
2007-09-27 7:56 ` [git] CFS-devel, latest code Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2007-10-02 19:49 Dmitry Adamushko
2007-10-02 19:59 ` Dmitry Adamushko
2007-10-03 4:15 ` Srivatsa Vaddagiri
2007-10-04 7:40 ` Ingo Molnar
2007-10-04 7:41 ` Ingo Molnar
2007-09-30 19:18 Dmitry Adamushko
2007-09-30 19:15 Dmitry Adamushko
2007-10-01 5:53 ` Mike Galbraith
2007-10-01 5:55 ` Ingo Molnar
2007-09-30 19:13 Dmitry Adamushko
2007-10-01 6:11 ` Ingo Molnar
2007-09-25 14:44 Ingo Molnar
2007-09-25 16:04 ` Srivatsa Vaddagiri
2007-09-25 16:08 ` Srivatsa Vaddagiri
2007-09-24 21:45 Ingo Molnar
2007-09-24 21:55 ` Andrew Morton
2007-09-24 21:59 ` Ingo Molnar
2007-09-25 0:08 ` Daniel Walker
2007-09-25 6:45 ` Ingo Molnar
2007-09-25 15:17 ` Daniel Walker
2007-09-25 6:10 ` Mike Galbraith
2007-09-25 7:35 ` Mike Galbraith
2007-09-25 8:33 ` Mike Galbraith
2007-09-25 8:53 ` Srivatsa Vaddagiri
2007-09-25 9:11 ` Srivatsa Vaddagiri
2007-09-25 9:15 ` Mike Galbraith
2007-09-25 9:12 ` Mike Galbraith
2007-09-25 9:13 ` Ingo Molnar
2007-09-25 9:17 ` Mike Galbraith
2007-09-25 9:47 ` Ingo Molnar
2007-09-25 10:02 ` Mike Galbraith
2007-09-26 8:04 ` Mike Galbraith
2007-09-28 21:46 ` Bill Davidsen
2007-09-25 9:44 ` Srivatsa Vaddagiri
2007-09-25 9:40 ` Ingo Molnar
2007-09-25 10:10 ` Ingo Molnar
2007-09-25 10:28 ` Srivatsa Vaddagiri
2007-09-25 10:36 ` Ingo Molnar
2007-09-25 11:33 ` Ingo Molnar
2007-09-25 14:48 ` Srivatsa Vaddagiri
2007-09-25 12:51 ` Srivatsa Vaddagiri
2007-09-25 13:35 ` Mike Galbraith
2007-09-25 14:07 ` Srivatsa Vaddagiri
2007-09-25 12:28 ` Mike Galbraith
2007-09-25 12:54 ` Mike Galbraith
2007-09-25 6:50 ` S.Çağlar Onur
2007-09-25 9:17 ` Ingo Molnar
2007-09-25 7:41 ` Andrew Morton
2007-09-25 8:43 ` Srivatsa Vaddagiri
2007-09-25 8:48 ` Andrew Morton
2007-09-25 11:00 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1190756127.18744.23.camel@earth \
--to=dmitry.adamushko@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox