From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751762AbdATQxu (ORCPT ); Fri, 20 Jan 2017 11:53:50 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:59358 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751201AbdATQxt (ORCPT ); Fri, 20 Jan 2017 11:53:49 -0500 Date: Fri, 20 Jan 2017 17:52:11 +0100 From: Peter Zijlstra To: Steven Rostedt Cc: LKML , Ingo Molnar , Andrew Morton Subject: Re: [PATCH] sched: Optimize pick_next_task for idle_sched_class too Message-ID: <20170120165211.GR6485@twins.programming.kicks-ass.net> References: <20170119101703.2abeaeb6@gandalf.local.home> <20170119174408.GN6485@twins.programming.kicks-ass.net> <20170120111425.5afaad5c@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170120111425.5afaad5c@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 Fri, Jan 20, 2017 at 11:14:25AM -0500, Steven Rostedt wrote: > > OK, so I hate this patch because it makes the condition more complex, > > and while staring at what it does for code generation I couldn't for the > > life of me figure out why we care about prev->sched_class to begin with. > > I was thinking it would save on checking the rq at all, but rq is used > by pick_next_task_*() anyway, so I doubt it's much savings. fwiw, code generation adds something like: CMP imm32, reg JE imm8 So the overhead is not immense, something like 7-8 bytes, but still, less is more :-)