From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932455AbcFOLPI (ORCPT ); Wed, 15 Jun 2016 07:15:08 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:50512 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932114AbcFOLO7 (ORCPT ); Wed, 15 Jun 2016 07:14:59 -0400 Date: Wed, 15 Jun 2016 13:14:53 +0200 From: Peter Zijlstra To: Steven Rostedt Cc: LKML , Ingo Molnar , Thomas Gleixner , Clark Williams , Andrew Morton , Nick Piggin Subject: Re: [PATCH] sched: Do not release current rq lock on non contended double_lock_balance() Message-ID: <20160615111453.GG30909@twins.programming.kicks-ass.net> References: <20160613123732.3a8ccc57@gandalf.local.home> <20160614115820.GD30921@twins.programming.kicks-ass.net> <20160614140228.0ecf15af@grimm.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160614140228.0ecf15af@grimm.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, Jun 14, 2016 at 02:02:28PM -0400, Steven Rostedt wrote: > > For instance; pull_rt_task() does: > > > > for_each_cpu() { > > double_lock_balance(this, that); > > ... > > double_unlock_balance(this, that); > > } > > > > Which, with the trylock, ends up with a max possible hold time of > > O(nr_cpus). > > Sure, but I think we should try to limit that loop too, because that > loop itself is what is triggering the large latency for me, because > it constantly releases a spinlock and has to wait. This loop is done > with preemption disabled. OK, so should not the whole HAVE_RT_PUSH_IPI thing have avoided that loop entirely? And therefore made the point moot? In any case, can't we add another cpupri for pushable tasks and use that to find the highest priority task to pull and avoid the loop thus?