Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1240607 > unrolled thread
| Started by | Yuyang Du <yuyang.du@intel.com> |
|---|---|
| First post | 2015-10-06 17:50 +0200 |
| Last post | 2015-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.
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
| From | Yuyang Du <yuyang.du@intel.com> |
|---|---|
| Date | 2015-10-06 17:50 +0200 |
| Subject | Re: [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]
| From | Yuyang Du <yuyang.du@intel.com> |
|---|---|
| Date | 2015-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