Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote:
> On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault
> <samuel.thiba...@ens-lyon.org> wrote:
> > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote:
> >> >> > - if (shares < MIN_SHARES)
> >> >> > - shares = MIN_SHARES;
> >> > ...
> >> >> > return shares;
> >> >
> >> > This will only make sure that the returned shares is 2, not 2048.
> >>
> >> This is intentional. The MIN_SHARES you are seeing here is overloaded.
> >> Every "1" unit of share is "SCHED_LOAD_RESOLUTION" bits internally.
> >
> > I'm not talking about the SCHED_LOAD_RESOLUTION scaling, but about the
> > SCHED_FIXEDPOINT_SHIFT scaling, which is what
> > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit
> > kernels")
> > modified on 64bit platforms.
>
> .... From that commit:
>
> """
> -#if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power
> usage under light load */
> +#ifdef CONFIG_64BIT
> # define SCHED_LOAD_RESOLUTION 10
> # define scale_load(w) ((w) << SCHED_LOAD_RESOLUTION)
> # define scale_load_down(w) ((w) >> SCHED_LOAD_RESOLUTION)
Errgl, sorry, I was referring to the old naming. This stuff has seen
so much patching over and over in the past revisions... It though you
were referring to SCHED_CAPACITY_SCALE. The code I was reading now uses
SCHED_LOAD_RESOLUTION, so that's why I read your "SCHED_LOAD_RESOLUTION"
as "the other scaling".
> The MIN_SHARES you are seeing here is overloaded.
> In the unscaled case this needs to be MIN_SHARES, and in the scaled
> case, the subdivision of the scaled values must still be >=2.
Ok, now I understand. I have to say this overloading is confusing.
Samuel
