From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752737AbaEOCt7 (ORCPT ); Wed, 14 May 2014 22:49:59 -0400 Received: from mail-ee0-f46.google.com ([74.125.83.46]:54839 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbaEOCt5 (ORCPT ); Wed, 14 May 2014 22:49:57 -0400 Message-ID: <1400122194.5175.18.camel@marge.simpson.net> Subject: Re: [PATCH] sched/rt: don't try to balance rt_runtime when it is futile From: Mike Galbraith To: Paul Gortmaker Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, Ingo Molnar , Frederic Weisbecker , Peter Zijlstra , Steven Rostedt , Thomas Gleixner Date: Thu, 15 May 2014 04:49:54 +0200 In-Reply-To: <20140514191100.GA24155@windriver.com> References: <1400080115-12339-1-git-send-email-paul.gortmaker@windriver.com> <20140514154459.GE4570@linux.vnet.ibm.com> <20140514191100.GA24155@windriver.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-05-14 at 15:11 -0400, Paul Gortmaker wrote: > Given that, perhaps a separate change to sched_rt_runtime_exceeded() > that works out the CPU from the rt_rq, and returns zero if it is a > nohz_full cpu? Does that make sense? Then the nohz_full people won't > get the throttling message even if they go 100%. I don't get it. What reason would there be to run a hog on a dedicated core as realtime policy/priority? Given no competition, there's nothing to prioritize, you could just as well run a critical task as SCHED_IDLE. I would also expect that anyone wanting bare metal will have all of their critical cores isolated from the scheduler, watchdogs turned off as well as that noisy throttle, the whole point being to make as much silent as possible. Seems to me tick_nohz_full_cpu(cpu) should be predicated by that cpu being isolated from the #1 noise source, the scheduler and its load balancing. There's just no point to nohz_full without that, or if there is, I sure don't see it. When I see people trying to run a hog as a realtime task, it's because they are trying in vain to keep competition away from precious cores.. and one mlockall with a realtime hog blocking flush_work() gives them a wakeup call. -Mike