linux-kernel - Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20150422230122.3637f11f@grimm.local.home>
Date:	Wed, 22 Apr 2015 23:01:22 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	pang.xunlei@....com.cn
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...il.com>,
	linux-kernel@...r.kernel.org, Xunlei Pang <pang.xunlei@...aro.org>
Subject: Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for
 equal prio cases

On Thu, 23 Apr 2015 09:35:12 +0800
pang.xunlei@....com.cn wrote:

> Hi Steve, Peter,
> 
> Steven Rostedt <rostedt@...dmis.org> wrote 2015-04-21 AM 01:48:03:
> > On Mon, 20 Apr 2015 19:20:48 +0200
> > Peter Zijlstra <peterz@...radead.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/