From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752951AbdLDKex (ORCPT ); Mon, 4 Dec 2017 05:34:53 -0500 Received: from mail.monom.org ([188.138.9.77]:50610 "EHLO mail.monom.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbdLDKew (ORCPT ); Mon, 4 Dec 2017 05:34:52 -0500 X-Greylist: delayed 327 seconds by postgrey-1.27 at vger.kernel.org; Mon, 04 Dec 2017 05:34:51 EST Subject: Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull To: Steven Rostedt , LKML , linux-rt-users Cc: Ingo Molnar , Peter Zijlstra , Sebastian Andrzej Siewior , Thomas Gleixner References: <20171202130454.4cbbfe8d@vmware.local.home> From: Daniel Wagner Message-ID: <6564b433-f820-67b7-76fc-bdb442979a7d@monom.org> Date: Mon, 4 Dec 2017 11:29:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171202130454.4cbbfe8d@vmware.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, On 12/02/2017 07:04 PM, Steven Rostedt wrote: > Daniel Wagner reported a crash on the beaglebone black. This is a > single CPU architecture, and does not have a functional: > arch_send_call_function_single_ipi() and can crash if that is called. > > As it only has one CPU, it shouldn't be called, but if the kernel is > compiled for SMP, the push/pull RT scheduling logic now calls it for > irq_work if the one CPU is overloaded, it can use that function to call > itself and crash the kernel. > > Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system > only has a single CPU. But SCHED_FEAT is a constant if sched debugging > is turned off. Another fix can also be used, and this should also help > with normal SMP machines. That is, do not initiate the pull code if > there's only one RT overloaded CPU, and that CPU happens to be the > current CPU that is scheduling in a lower priority task. > > Even on a system with many CPUs, if there's many RT tasks waiting to > run on a single CPU, and that CPU schedules in another RT task of lower > priority, it will initiate the PULL logic in case there's a higher > priority RT task on another CPU that is waiting to run. But if there is > no other CPU with waiting RT tasks, it will initiate the RT pull logic > on itself (as it still has RT tasks waiting to run). This is a wasted > effort. > > Not only does this help with SMP code where the current CPU is the only > one with RT overloaded tasks, it should also solve the issue that > Daniel encountered, because it will prevent the PULL logic from > executing, as there's only one CPU on the system, and the check added > here will cause it to exit the RT pull code. > > Link: http://lkml.kernel.org/r/8c913cc2-b2e3-8c2e-e503-aff1428f8ff5@monom.org > Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic") > Cc: stable@vger.kernel.org > Reported-by: Daniel Wagner Tested-by: Daniel Wagner Thanks, Daniel