On Wed, Oct 14, 2015 at 11:30:24AM +0200, Peter Zijlstra wrote: > 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, [email protected] 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.
ok, i will take the optimization into account in the migration case. thanks, byungchul > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
