From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbdCAJrx (ORCPT ); Wed, 1 Mar 2017 04:47:53 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:54996 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751461AbdCAJrr (ORCPT ); Wed, 1 Mar 2017 04:47:47 -0500 Date: Wed, 1 Mar 2017 09:37:01 +0100 From: Peter Zijlstra To: Steven Rostedt Cc: Ingo Molnar , LKML , Andrew Morton Subject: Re: [PATCH] sched/rt: Document why has_pushable_tasks() isn't called with a runqueue lock Message-ID: <20170301083701.GX6515@twins.programming.kicks-ass.net> References: <20170228164856.3d2e81bd@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170228164856.3d2e81bd@gandalf.local.home> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 28, 2017 at 04:48:56PM -0500, Steven Rostedt wrote: > + /* > + * Normally, has_pushable_tasks() would be performed within the > + * runqueue lock being held. But if it was not set when entering "not set" what? I'm having trouble parsing this. > + * this hard interrupt handler function, then to have it set would > + * require a wake up. A wake up of an RT task will either cause a > + * schedule if the woken task is higher priority than the running > + * task, or it would try to do a push from the CPU doing the wake > + * up. Grabbing the runqueue lock in such a case would more likely > + * just cause unnecessary contention. > + */ > if (has_pushable_tasks(rq)) { > raw_spin_lock(&rq->lock); > push_rt_task(rq);