Messages in this thread | | | Date | Wed, 15 Mar 2006 09:45:37 +1100 | From | Peter Williams <> | Subject | Re: [PATCH][2/4] sched: add discrete weighted cpu load function |
| |
Con Kolivas wrote: > On Wednesday 15 March 2006 09:09, Peter Williams wrote: > >>Con Kolivas wrote: >> >>>Peter Williams writes: >>> >>>>Con Kolivas wrote: >>>> >>>>>+unsigned long weighted_cpuload(const int cpu) >>>>>+{ >>>>>+ return (cpu_rq(cpu)->raw_weighted_load); >>>>>+} >>>>>+ >>>> >>>>Wouldn't this be a candidate for inlining? >>> >>>That would make it unsuitable for exporting via sched.h. >> >>If above_background_load() were implemented inside sched.c instead of in >>sched.h there would be no need to export weighted_cpuload() would there? >> This would allow weighted_cpuload() to be inline and the efficiency >>would be better as above_background_load() doesn't gain a lot by being >>inline > > > I don't care about above_background_load() being inline; that's done because > all functions in header files need to be static inline to not become a mess. > > >>as having weighted_cpulpad() non inline means that it's doing a >>function call several times in a loop i.e. it may save one function call >>by being inline but requires (up to) one function call for every CPU. > > > I haven't checked but gcc may well inline weighted_cpuload anyway?
It may be doing so for internal uses inside sched.c but I'm pretty sure that it won't for external calls.
> We're > moving away from inlining most things manually since the compiler is doing it > well these days. >
OK. Even without explicit inlining you need to give the compiler a chance to optimize function call overhead away. It cant do that with the present arrangement.
> >>The other way around the cost would be just one function call. > > > The way you're suggesting adds a function that is never used by anything but > swap prefetch which would then need to be 'ifdef'ed out to not be needlessly > built on every system. Adding ifdefs is frowned upon already, and to have an > mm/ specific ifdef in sched.c would be rather ugly.
Sometimes ugliness is the best option.
Peter -- Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |