Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752385AbcKGUdW (ORCPT ); Mon, 7 Nov 2016 15:33:22 -0500 Received: from smtpi-sp-232.kinghost.net ([177.185.201.232]:50571 "EHLO smtpi-sp-232.kinghost.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752008AbcKGUdU (ORCPT ); Mon, 7 Nov 2016 15:33:20 -0500 Subject: Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature To: Steven Rostedt References: <20161107133207.4282de69@gandalf.local.home> <20161107144738.4811a5dd@gandalf.local.home> <20161107150003.66777b43@gandalf.local.home> <1e79f711-95f1-da2f-f572-1ac4329c8be7@bristot.me> <20161107151617.486b1b42@gandalf.local.home> Cc: Christoph Lameter , Daniel Bristot de Oliveira , Ingo Molnar , Peter Zijlstra , linux-rt-users , LKML From: Daniel Bristot de Oliveira Message-ID: Date: Mon, 7 Nov 2016 21:33:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161107151617.486b1b42@gandalf.local.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1325 Lines: 33 On 11/07/2016 09:16 PM, Steven Rostedt wrote: > I'm confused? Are you saying that RR tasks don't get throttled in the > current code? That sounds like a bug to me. If the RT_RUNTIME_SHARING is enabled, the CPU in which the RR tasks are running (and pinned) will borrow RT runtime from another CPU, allowing the RR tasks to run forever. For example: [root@kiron debug]# cat /proc/sched_debug | grep rt_runtime .rt_runtime : 950.000000 .rt_runtime : 950.000000 .rt_runtime : 950.000000 .rt_runtime : 950.000000 [root@kiron debug]# echo RT_RUNTIME_SHARE > sched_features [root@kiron debug]# taskset -c 2 chrt -r 5 /home/bristot/f & [1] 23908 [root@kiron debug]# taskset -c 2 chrt -r 5 /home/bristot/f & [2] 23915 [root@kiron debug]# cat /proc/sched_debug | grep rt_runtime .rt_runtime : 900.000000 .rt_runtime : 950.000000 .rt_runtime : 1000.000000 .rt_runtime : 950.000000 You see? the rt_runtime of the CPU 2 was borrowed time from CPU 0. It is not a BUG but a feature (no jokes haha). With RT_RUNTIME_SHARE, the rt_runtime is such a global runtime. It works fine for tasks that can migrate... but that is not the case for per-cpu kworkers. -- Daniel