On 19/10/2007, Steven Rostedt <[email protected]> wrote:
> [ ... ]
> Index: linux-test.git/kernel/sched.c
> ===================================================================
> --- linux-test.git.orig/kernel/sched.c 2007-10-19 12:32:39.000000000 -0400
> +++ linux-test.git/kernel/sched.c 2007-10-19 12:33:09.000000000 -0400
> @@ -300,6 +300,8 @@ struct rq {
> */
> unsigned long nr_uninterruptible;
>
> + unsigned long rt_nr_running;
could it be a part of the 'struct rt_rq' instead?
>
> +static inline void inc_rt_tasks(struct task_struct *p, struct rq *rq)
> +{
> + if (rt_task(p))
> + rq->rt_nr_running++;
> +}
> +
> +static inline void dec_rt_tasks(struct task_struct *p, struct rq *rq)
> +{
> + if (rt_task(p)) {
> + WARN_ON(!rq->rt_nr_running);
> + rq->rt_nr_running--;
> + }
> +}
> +
> static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)
> {
> struct rt_prio_array *array = &rq->rt.active;
>
> list_add_tail(&p->run_list, array->queue + p->prio);
> __set_bit(p->prio, array->bitmap);
> +
> + inc_rt_tasks(p, rq);
why do you need the rt_task(p) check in {inc,dec}_rt_tasks() ?
{enqueue,dequeue}_task_rt() seem to be the only callers and they will
crash (or corrupt memory) anyway in the case of ! rt_task(p) (sure,
this case would mean something is broken somewhere wrt sched_class
handling).
--
Best regards,
Dmitry Adamushko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
