Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases
From: Steven Rostedt
Date: Wed Apr 22 2015 - 23:01:26 EST
On Thu, 23 Apr 2015 09:35:12 +0800
pang.xunlei@xxxxxxxxxx wrote:
> Hi Steve, Peter,
>
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote 2015-04-21 AM 01:48:03:
> > On Mon, 20 Apr 2015 19:20:48 +0200
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > > > > + */
> > > > > + if (preempt_count() & PREEMPT_ACTIVE)
> > > > > + enqueue_pushable_task_preempted(rq, p);
> > > > > + else
> > > > > + enqueue_pushable_task(rq, p);
> > > > > + }
> > > > > }
> > >
> > > This looks wrong, what do you want to find? _any_ preemption? In that
> > > case PREEMPT_ACTIVE is wrong. What you need to check is if the task is
> > > still on the RQ or not.
> > >
> > > If the task was put to sleep it got dequeued, if it was not dequeued,
> it
> > > got preempted.
> > >
> > > PREEMPT_ACTIVE is only ever set for forced kernel preemption, which is
> a
> > > special sub case only ever triggered with CONFIG_PREEMPT=y.
> >
> > Ah, you're right. I was thinking of just forced preemption, but, I
> > wasn't thinking about voluntary preemption (preemption points). We want
> > this behavior for that too (for kernel).
> >
> > And yes, if we preempt in user space, this isn't enough either.
>
> Thanks, I understood this.
>
> So, we can't rely on PREEMPT_ACTIVE to do the job.
> Even for forced kernel preemption, it will be problematic for
> RR policy when running out of time slice in task_tick_rt(),
> as it calls resched_curr() to do the reschedule.
>
> So, I think we need to add a flag in task_struct and set it
> properly when doing real preemption.
>
> How about my unfinished patch below for this idea?
>
Why not use Peter's idea of instead of checking PREEMPT_ACTIVE, just
check if the task is on the runqueue or not. If it scheduled out, it
would take itself off the runqueue, if it was preempted by anything, it
would still be on the run queue, and according to FIFO, it should still
maintain CPU ownership over other tasks of the same prio.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/