From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753129AbbJNJad (ORCPT ); Wed, 14 Oct 2015 05:30:33 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:42356 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbbJNJaa (ORCPT ); Wed, 14 Oct 2015 05:30:30 -0400 Date: Wed, 14 Oct 2015 11:30:24 +0200 From: Peter Zijlstra To: Byungchul Park Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, yuyang.du@intel.com, pjt@google.com, efault@gmx.de, tglx@linutronix.de Subject: Re: [PATCH v2 1/2] sched: make each sched class handle its rq assignment in their own class Message-ID: <20151014093024.GB3816@twins.programming.kicks-ass.net> References: <1444812130-17880-1-git-send-email-byungchul.park@lge.com> <1444812130-17880-2-git-send-email-byungchul.park@lge.com> <20151014090016.GR17308@twins.programming.kicks-ass.net> <20151014092630.GX6455@byungchulpark-X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151014092630.GX6455@byungchulpark-X58A-UD3R> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 14, 2015 at 06:26:30PM +0900, Byungchul Park wrote: > On Wed, Oct 14, 2015 at 11:00:16AM +0200, Peter Zijlstra wrote: > > On Wed, Oct 14, 2015 at 05:42:09PM +0900, byungchul.park@lge.com wrote: > > > +static inline void set_task_rq(struct task_struct *p, unsigned int cpu) > > > +{ > > > + const struct sched_class *class; > > > + > > > + for_each_class(class) { > > > + if (class->set_task_rq) > > > + class->set_task_rq(p, cpu); > > > + } > > > +} > > > > So I worry about this, because the class structures are not all in the > > same translation unit, GCC cannot (without -fwhole-program) optimize > > that all away. > > i wondered if it was so, and it was. --combine might be enough, and might make sense for all the kernel/sched/ file, but that too is not something we currently do. > > This means we'll do 5 cacheline loads and 2 indirect calls, on _every_ > > cpu migration. > > i agree with your this concern. to avoid this concern, it can be done by > hard coding as current code.. but we will lose code flexability. i thought > migration overhead was not so important since it hardly happens. It happens quite a lot, just not _as_ often as regular context switching.