Re: [PATCH 1/4] sched/fair: Generalize the load/util averages resolution definition

[Yuyang Du]

On Mon, Oct 05, 2015 at 09:04:45AM +0200, Ingo Molnar wrote:
> 
> * Yuyang Du <yuyang.du@xxxxxxxxx> wrote:
> 
> > +# define SCHED_RESOLUTION_SHIFT	10
> 
> >  #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load  */
> 
> Might be worth fixing?

Yes, it should be. Peter has already brought this up.
 
> Also, I noticed this:
> 
> > -# define SCHED_LOAD_RESOLUTION	10
> > +# define SCHED_LOAD_SHIFT	(SCHED_RESOLUTION_SHIFT + SCHED_RESOLUTION_SHIFT)
> 
> So in the #if 0 (inactive) section we change it from 10 to 20 ...
> 
> > -# define SCHED_LOAD_RESOLUTION	0
> > +# define SCHED_LOAD_SHIFT	(SCHED_RESOLUTION_SHIFT)
> >  # define scale_load(w)		(w)
> >  # define scale_load_down(w)	(w)
> >  #endif
> >  
> > -#define SCHED_LOAD_SHIFT	(10 + SCHED_LOAD_RESOLUTION)
> 
> ... then we change the actually active definition from 20 to 10?
> 
> Was that intended?

Yes, it is intended. And it is atually the same question as your previous
one.

This is about whether we have the discrepancy between weight (user can
assign) and load (used by CFS to charge the task).

And this is about the precison of charging vs. the precision of the
proportional runtime (weight) the CFS promises to provide.

As charging happens millions of times, accumulative error is the concern.

The comments said increasing load resolution improves the small weight
task share distribution.

However, as charging is done like runtime / load, runtime is real time
in ns, a big numbeer, so higher/bigger load may lead to more drift?
Because the error of the integer division is about the same as the divider?
 
Or as higher load is used, maybe we fix this (remove the bloody #if 0)
by making it a CONFIG_ ?

> Please double check the 'make allyesconfig' disassembly of kernel/sched/built-in.o 
> before/after this patch to make sure it does not change any code.
> 
> ( No full allyesconfig build needed: 'make -j16 kernel/sched' should cut down on
>   the build time. )

I checked. Unfortunately, before differs from after. But the difference
should not be caused by this patch, as this patch does not make any
difference after macro expansion.

 
> Thanks,
> 
> 	Ingo
--
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/