From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751824AbdEPIPF (ORCPT ); Tue, 16 May 2017 04:15:05 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:49455 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbdEPIPD (ORCPT ); Tue, 16 May 2017 04:15:03 -0400 Date: Tue, 16 May 2017 10:14:53 +0200 From: Peter Zijlstra To: Dave Kleikamp Cc: LKML , Ingo Molnar Subject: Re: [PATCH RESEND 1/1] sched/rt: minimize rq->lock contention in, do_sched_rt_period_timer() Message-ID: <20170516081453.titdkpplakvhzydw@hirez.programming.kicks-ass.net> References: <741689b4-2e37-bdfe-5953-bb954fe5c35a@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2017 at 02:14:13PM -0500, Dave Kleikamp wrote: > With CONFIG_RT_GROUP_SCHED defined, do_sched_rt_period_timer() sequentially > takes each cpu's rq->lock. On a large, busy system, the cumulative time it > takes to acquire each lock can be excessive, even triggering a watchdog > timeout. > > If rt_rq_rt_time and rt_rq->rt_nr_running are both zero, this function does > nothing while holding the lock, so don't bother taking it at all. Indeed, thanks Dave!