All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <dhillf@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Mike Galbraith <efault@gmx.de>,
	Yong Zhang <yong.zhang0@gmail.com>
Subject: Re: [PATCH] sched: remove starvation in check_preempt_equal_prio()
Date: Tue, 24 May 2011 22:11:58 +0800	[thread overview]
Message-ID: <BANLkTim0RtCjefq5Z2qbJFbBhrCHFfeGxg@mail.gmail.com> (raw)
In-Reply-To: <1306244745.1465.62.camel@gandalf.stny.rr.com>

On Tue, May 24, 2011 at 9:45 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 2011-05-24 at 21:34 +0800, Hillf Danton wrote:
>> If there are pushable tasks and they are high enough in priority, in which
>> case task p is covered, the current could keep holding its CPU.
>>
>> Even if current task has to release its CPU, requeuing task p could result in
>> starvation of tasks that are of same priority and have been waiting on RQ for
>> a couple of hours:/
>
> Can you explain this better? Sounds like you are describing the
> definition of FIFO. You are *not* suppose to preempt a FIFO task just

I dont want to redefine FIFO, but starvation needs attention, since
the woken task is already off RQ, and its position on RQ is reshuffled.

thanks
          Hillf
> because another task of equal priority woke up on its run queue.
>
> Yes, if you queue two FIFO tasks of the same priority on the same run
> queue, and one runs for hours without calling schedule. The other one
> will have to wait.
>
> -- Steve
>
>
>>
>> Signed-off-by: Hillf Danton <dhillf@gmail.com>
>> ---
>>
>> --- tip-git/kernel/sched_rt.c Sun May 22 20:12:01 2011
>> +++ sched_rt.c        Tue May 24 21:01:51 2011
>> @@ -1028,24 +1028,23 @@ select_task_rq_rt(struct task_struct *p,
>>       return cpu;
>>  }
>>
>> +static struct task_struct *pick_next_pushable_task(struct rq *);
>> +
>>  static void check_preempt_equal_prio(struct rq *rq, struct task_struct *p)
>>  {
>> -     if (rq->curr->rt.nr_cpus_allowed == 1)
>> -             return;
>> -
>> -     if (p->rt.nr_cpus_allowed != 1
>> -         && cpupri_find(&rq->rd->cpupri, p, NULL))
>> +     if (rq->curr->rt.nr_cpus_allowed > 1) {
>> +             struct task_struct *push = pick_next_pushable_task(rq);
>> +             /*
>> +              * Though curr is pushable, if there are other pushable tasks,
>> +              * we keep curr busy.
>> +              */
>> +             if (push && !(push->prio > p->prio))
>> +                     return;
>> +     } else
>>               return;
>>
>> -     if (!cpupri_find(&rq->rd->cpupri, rq->curr, NULL))
>> -             return;
>> -
>> -     /*
>> -      * There appears to be other cpus that can accept
>> -      * current and none to run 'p', so lets reschedule
>> -      * to try and push current away:
>> -      */
>> -     requeue_task_rt(rq, p, 1);
>> +     /* yield curr */
>> +     requeue_task_rt(rq, rq->curr, 0);
>>       resched_task(rq->curr);
>>  }
>>
>> @@ -1091,7 +1090,7 @@ static struct sched_rt_entity *pick_next
>>       BUG_ON(idx >= MAX_RT_PRIO);
>>
>>       queue = array->queue + idx;
>> -     next = list_entry(queue->next, struct sched_rt_entity, run_list);
>> +     next = list_first_entry(queue, struct sched_rt_entity, run_list);
>>
>>       return next;
>>  }
>
>
>

  reply	other threads:[~2011-05-24 14:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 13:34 [PATCH] sched: remove starvation in check_preempt_equal_prio() Hillf Danton
2011-05-24 13:45 ` Steven Rostedt
2011-05-24 14:11   ` Hillf Danton [this message]
2011-05-24 14:22     ` Steven Rostedt
2011-05-24 13:47 ` Peter Zijlstra
2011-05-24 14:01   ` Hillf Danton
2011-05-24 14:24     ` Steven Rostedt
2011-05-24 14:33       ` Hillf Danton
2011-05-24 14:46         ` Steven Rostedt
2011-05-24 15:04           ` Hillf Danton
2011-05-25 14:00           ` Hillf Danton
2011-05-25 14:13             ` Steven Rostedt

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=BANLkTim0RtCjefq5Z2qbJFbBhrCHFfeGxg@mail.gmail.com \
    --to=dhillf@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=yong.zhang0@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.