Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1240607 > unrolled thread

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

Started byYuyang Du <yuyang.du@intel.com>
First post2015-10-06 17:50 +0200
Last post2015-10-10 09:00 +0200
Articles 2 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 1/4] sched/fair: Generalize the load/util averages  resolution definition Yuyang Du <yuyang.du@intel.com> - 2015-10-06 17:50 +0200
    Re: [PATCH 1/4] sched/fair: Generalize the load/util averages  resolution definition Yuyang Du <yuyang.du@intel.com> - 2015-10-10 09:00 +0200

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

FromYuyang Du <yuyang.du@intel.com>
Date2015-10-06 17:50 +0200
SubjectRe: [PATCH 1/4] sched/fair: Generalize the load/util averages resolution definition
Message-ID<qgCF4-20n-13@gated-at.bofh.it>
On Mon, Oct 05, 2015 at 09:04:45AM +0200, Ingo Molnar wrote:
> 
> * Yuyang Du <yuyang.du@intel.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1243837

FromYuyang Du <yuyang.du@intel.com>
Date2015-10-10 09:00 +0200
Message-ID<qhWim-1C7-9@gated-at.bofh.it>
In reply to#1240607
On Tue, Oct 06, 2015 at 04:00:00PM +0800, Yuyang Du wrote:
> On Mon, Oct 05, 2015 at 09:04:45AM +0200, Ingo Molnar wrote:
> > 
> > * Yuyang Du <yuyang.du@intel.com> 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.
  
Do you have any suggestion on how to fix this?

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web