Re: [PATCH 18/46] kernel: Mark functions as static in sched/fair.c

From: Josh Triplett
Date: Thu Feb 27 2014 - 11:03:41 EST


On Thu, Feb 27, 2014 at 12:58:05PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 05:20:19PM +0530, Rashika Kheria wrote:
> > @@ -5266,7 +5266,7 @@ static unsigned long default_scale_smt_power(struct sched_domain *sd, int cpu)
> > return smt_gain;
> > }
> >
> > -unsigned long __weak arch_scale_smt_power(struct sched_domain *sd, int cpu)
> > +static unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
> > {
> > return default_scale_smt_power(sd, cpu);
> > }
>
> Fuck no; please think before sending.
>
> I'm going to ignore all patches from you henceforth.

Did you perhaps check, and notice that there are *zero* uses of this
function in the kernel? Nothing overrides this weak symbol; it is no
longer needed. You removed the one and only user in your commit:

commit ee08d1284ea9235b29bd2d9b7493b4b4cf3da09c
Author: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Date: Wed Jun 13 15:24:45 2012 +0200

sched/x86: Remove broken power estimation

The x86 sched power implementation has been broken forever and gets in
the way of other stuff, remove it.

When I reviewed Rashika's patch and provided a Reviewed-by, I provided
the following feedback:

Josh Triplett wrote:
> I'd suggest waiting to see how the scheduler folks respond to this patch
> series, and then if they accept the changes marking unused __weak
> functions as static, you could follow up with a patch that folds them
> into their callers and gets rid of them entirely.

(That feedback was based on the assumption that the simplest possible
mark-it-static patch would be a good starting point.)

Now, given all of the above, perhaps you could provide some useful
feedback on what you find so objectionable about this patch?

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/