From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751838AbcBLXKY (ORCPT ); Fri, 12 Feb 2016 18:10:24 -0500 Received: from smtprelay0142.hostedemail.com ([216.40.44.142]:55646 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750981AbcBLXKX (ORCPT ); Fri, 12 Feb 2016 18:10:23 -0500 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2393:2559:2562:2693:2895:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3874:4250:4321:4605:5007:6261:6671:7875:7903:10004:10400:10848:11026:11658:11914:12043:12296:12438:12517:12519:12555:12663:13007:13161:13229:13618:14096:14097:14394:14659:21063:21067:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: fall69_5a755a0853c23 X-Filterd-Recvd-Size: 3487 Date: Fri, 12 Feb 2016 18:10:20 -0500 From: Steven Rostedt To: LKML Cc: Juri Lelli , Peter Zijlstra , Ingo Molnar , Clark Williams , Daniel Bristot de Oliveira , John Kacur Subject: [PATCH] sched/deadline: Always calculate end of period on sched_yield() Message-ID: <20160212181020.7dbaf326@gandalf.local.home> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm writing a test case for SCHED_DEADLINE, and notice a strange anomaly. Every so often, a deadline is missed and when I looked into it, it happened because the sched_yield() had no effect (it didn't end the previous period and let the start of the next runtime happen on the end of the old period). deadline-2228 7...1 116.778420: sys_enter_sched_yield: deadline-2228 7d..3 116.778421: hrtimer_cancel: hrtimer=0xffff88011ebd79a0 deadline-2228 7d..2 116.778422: rcu_utilization: Start context switch deadline-2228 7d..2 116.778423: rcu_utilization: End context switch deadline-2228 7d..4 116.778423: hrtimer_start: hrtimer=0xffff88011ebd79a0 function=hrtick/0x0 expires=116124420428 softexpires=116124420428 deadline-2228 7...1 116.778425: sys_exit_sched_yield: 0x0 Schedule was never called. A added some trace_printks() and discovered that this happens when sched_yield() is called right after a tick that updates its current bandwidth. When the schedule tick happens that updates the current bandwidth, update_curr_dl() is called, where it updates curr->se.exec_start to rq_clock_task(rq). The rq_clock_task(rq) gets updated by update_rq_clock_task() that gets update by various points in the scheduler. Now, if the user task calls sched_yield() just after a bandwidth update synced curr->se.exec_start to rq_clock_task(rq), when sched_yield() calls into update_curr_dl() we have: delta_exec = rq_clock_task(rq) - curr->se.exec_start; if (unlikely((s64)delta_exec <= 0)) return; Coming in here from a sched_yield() will have delta_exec == 0 if the sched_yield() was called after a DL tick and before another update_rq_clock_task() is called. This means that the task will not release its remaining runtime, and the will start off in the current period when it expected to be in the next period. The fix that appears to work for me is to add a test in update_curr_dl() to not exit if delta_exec is zero and dl_se->dl_yielded is true. Signed-off-by: Steven Rostedt --- diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index cd64c979d0e1..1dd180cda574 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -735,7 +735,7 @@ static void update_curr_dl(struct rq *rq) * approach need further study. */ delta_exec = rq_clock_task(rq) - curr->se.exec_start; - if (unlikely((s64)delta_exec <= 0)) + if (unlikely((s64)delta_exec <= 0 && !dl_se->dl_yielded)) return; schedstat_set(curr->se.statistics.exec_max,