From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758616AbbDWDBW (ORCPT ); Wed, 22 Apr 2015 23:01:22 -0400 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.228]:25116 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758600AbbDWDBT (ORCPT ); Wed, 22 Apr 2015 23:01:19 -0400 Date: Wed, 22 Apr 2015 23:01:22 -0400 From: Steven Rostedt To: pang.xunlei@zte.com.cn Cc: Peter Zijlstra , Juri Lelli , linux-kernel@vger.kernel.org, Xunlei Pang Subject: Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases Message-ID: <20150422230122.3637f11f@grimm.local.home> In-Reply-To: References: <1429518168-7965-1-git-send-email-xlpang@126.com> <1429518168-7965-2-git-send-email-xlpang@126.com> <20150420105228.461e103c@gandalf.local.home> <20150420172048.GZ27490@worktop.programming.kicks-ass.net> <20150420134803.5446e32d@gandalf.local.home> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Apr 2015 09:35:12 +0800 pang.xunlei@zte.com.cn wrote: > Hi Steve, Peter, > > Steven Rostedt wrote 2015-04-21 AM 01:48:03: > > On Mon, 20 Apr 2015 19:20:48 +0200 > > Peter Zijlstra 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