On Thu, 23 Apr 2015 09:35:12 +0800 pang.xun...@zte.com.cn wrote: > Hi Steve, Peter, > > Steven Rostedt <rost...@goodmis.org> wrote 2015-04-21 AM 01:48:03: > > On Mon, 20 Apr 2015 19:20:48 +0200 > > Peter Zijlstra <pet...@infradead.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
