From: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>
To: vatsa@linux.vnet.ibm.com
Cc: "Ingo Molnar" <mingo@elte.hu>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 5/6] core changes for group fairness
Date: Wed, 13 Jun 2007 22:56:06 +0200 [thread overview]
Message-ID: <b647ffbd0706131356q344af13as3744c151b4a4f680@mail.gmail.com> (raw)
In-Reply-To: <20070611155608.GE2109@in.ibm.com>
On 11/06/07, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote:
> This patch introduces the core changes in CFS required to accomplish
> group fairness at higher levels. It also modifies load balance interface
> between classes a bit, so that move_tasks (which is centric to load
> balance) can be reused to balance between runqueues of various types
> (struct rq in case of SCHED_RT tasks, struct lrq in case of
> SCHED_NORMAL/BATCH tasks).
a few things that catched my eye, please see below:
> +static int balance_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest,
> + unsigned long max_nr_move, unsigned long max_load_move,
> + struct sched_domain *sd, enum idle_type idle,
> + int *all_pinned, unsigned long *load_moved,
> + int this_best_prio, int best_prio, int best_prio_seen,
> + void *iterator_arg,
> + struct task_struct *(*iterator_start)(void *arg),
> + struct task_struct *(*iterator_next)(void *arg));
IMHO, it looks a bit frightening :) maybe it would be possible to
create a structure that combines some relevant argumens .. at least,
the last 3 ones.
> -static int move_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest,
> +static int balance_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest,
> unsigned long max_nr_move, unsigned long max_load_move,
> struct sched_domain *sd, enum idle_type idle,
> - int *all_pinned)
> + int *all_pinned, unsigned long *load_moved,
> + int this_best_prio, int best_prio, int best_prio_seen,
> + void *iterator_arg,
> + struct task_struct *(*iterator_start)(void *arg),
> + struct task_struct *(*iterator_next)(void *arg))
I think, there is a possible problem here. If I'm not complete wrong,
this function (move_tasks() in the current mainline) can move more
'load' than specified by the 'max_load_move'..
as a result, e.g. in the following code :
> +static int move_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest,
> + unsigned long max_nr_move, unsigned long max_load_move,
> + struct sched_domain *sd, enum idle_type idle,
> + int *all_pinned)
> +{
> + struct sched_class *class = sched_class_highest;
> + unsigned long load_moved, total_nr_moved = 0, nr_moved;
> +
> + do {
> + nr_moved = class->load_balance(this_rq, this_cpu, busiest,
> + max_nr_move, max_load_move, sd, idle,
> + all_pinned, &load_moved);
> + total_nr_moved += nr_moved;
> + max_nr_move -= nr_moved;
> + max_load_move -= load_moved;
can become negative.. and as it's 'unsigned' --> a huge positive number..
> + class = class->next;
> + } while (class && max_nr_move && max_load_move);
'(long)max_load_move > 0' ?
the same is applicable to a few other similar cases below :
> +static int
> +load_balance_fair(struct rq *this_rq, int this_cpu, struct rq *busiest,
> + unsigned long max_nr_move, unsigned long max_load_move,
> + struct sched_domain *sd, enum idle_type idle,
> + int *all_pinned, unsigned long *total_load_moved)
> +{
> + struct lrq *busy_lrq;
> + unsigned long load_moved, total_nr_moved = 0, nr_moved, rem_load_move;
> +
> + rem_load_move = max_load_move;
> +
> + for_each_leaf_lrq(busiest, busy_lrq) {
> + struct lrq *this_lrq;
> + long imbalance;
> + unsigned long maxload;
> + int this_best_prio, best_prio, best_prio_seen = 0;
> +
..........
> +
> + nr_moved = balance_tasks(this_rq, this_cpu, busiest,
> + max_nr_move, maxload, sd, idle, all_pinned,
> + &load_moved, this_best_prio, best_prio,
> + best_prio_seen,
> + /* pass busy_lrq argument into
> + * load_balance_[start|next]_fair iterators
> + */
> + busy_lrq,
> + load_balance_start_fair,
> + load_balance_next_fair);
> +
> + total_nr_moved += nr_moved;
> + max_nr_move -= nr_moved;
> + rem_load_move -= load_moved;
here
> +
> + /* todo: break if rem_load_move is < load_per_task */
> + if (!max_nr_move || !rem_load_move)
'(long)rem_load_move <= 0'
and I think somewhere else in the code.
> --
> Regards,
> vatsa
>
--
Best regards,
Dmitry Adamushko
next prev parent reply other threads:[~2007-06-13 20:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 15:47 [RFC][PATCH 0/6] Add group fairness to CFS - v1 Srivatsa Vaddagiri
2007-06-11 15:50 ` [RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq Srivatsa Vaddagiri
2007-06-11 18:48 ` Linus Torvalds
2007-06-11 18:56 ` Ingo Molnar
2007-06-12 2:15 ` [ckrm-tech] " Balbir Singh
2007-06-12 3:52 ` Srivatsa Vaddagiri
2007-06-11 15:52 ` [RFC][PATCH 2/6] task's cpu information needs to be always correct Srivatsa Vaddagiri
2007-06-12 2:17 ` [ckrm-tech] " Balbir Singh
2007-06-11 15:53 ` [RFC][PATCH 3/6] core changes in CFS Srivatsa Vaddagiri
2007-06-12 2:29 ` Balbir Singh
2007-06-12 4:22 ` Srivatsa Vaddagiri
2007-06-11 15:55 ` [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks Srivatsa Vaddagiri
2007-06-12 9:03 ` Dmitry Adamushko
2007-06-12 10:26 ` Srivatsa Vaddagiri
2007-06-12 12:23 ` Dmitry Adamushko
2007-06-12 13:30 ` Srivatsa Vaddagiri
2007-06-12 14:31 ` Dmitry Adamushko
2007-06-12 15:43 ` Srivatsa Vaddagiri
2007-06-11 15:56 ` [RFC][PATCH 5/6] core changes for group fairness Srivatsa Vaddagiri
2007-06-13 20:56 ` Dmitry Adamushko [this message]
2007-06-14 12:06 ` Srivatsa Vaddagiri
2007-06-11 15:58 ` [RFC][PATCH 6/6] Hook up to container infrastructure Srivatsa Vaddagiri
2007-06-11 16:02 ` [RFC][PATCH 0/6] Add group fairness to CFS - v1 Srivatsa Vaddagiri
2007-06-11 19:37 ` Ingo Molnar
2007-06-11 19:39 ` Ingo Molnar
2007-06-12 5:50 ` Srivatsa Vaddagiri
2007-06-12 6:26 ` Ingo Molnar
[not found] ` <20070612072742.GA785@in.ibm.com>
2007-06-12 10:56 ` Srivatsa Vaddagiri
2007-06-15 12:46 ` Kirill Korotaev
2007-06-15 14:06 ` Srivatsa Vaddagiri
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=b647ffbd0706131356q344af13as3744c151b4a4f680@mail.gmail.com \
--to=dmitry.adamushko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vatsa@linux.vnet.ibm.com \
/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
all inboxes | Powered by JetHome®