Messages in this thread | | | Date | Wed, 11 Nov 2015 18:38:10 +0900 | From | Byungchul Park <> | Subject | Re: [PATCH v5 0/2] sched: consider missed ticks when updating cpu load |
| |
On Tue, Nov 10, 2015 at 09:36:00AM +0900, byungchul.park@lge.com wrote: > From: Byungchul Park <byungchul.park@lge.com> > > change from v4 to v5 > - fix comments and commit message > - take new_load into account in update_cpu_load_nohz() and __update_cpu_load() > because it's non-zero in NOHZ_FULL > > change from v3 to v4 > - focus the problem on full NOHZ > > change from v2 to v3 > - add a patch which make __update_cpu_load() handle active tickless > > change from v1 to v2 > - add some additional commit message (logic is same exactly) > > additionally i tried to use the return value of hrtimer_forward() instead of > jiffies to get pending tick for updating cpu load. it's easy for > update_cpu_load_nohz() to do that. but for update_idle_cpu_load(), i need > more time to think about how to implement it nicely.
Actually because of update_idle_load() which is used when doing nohz load balancing while the cpu has been still tick-stopped, this looks not be able to be implemented without any kind of last_update_xxx variable. What do you think about it, Peter?
> > and i will try to fix other stuffs caused by full NOHZ later with another > patch. i decided to send this patch at first because "cpu load update" is a > standalone problem which is not coupled with other stuffs. > > Byungchul Park (2): > sched: make __update_cpu_load() handle NOHZ_FULL tickless > sched: make update_cpu_load_nohz() consider missed ticks in NOHZ_FULL > > include/linux/sched.h | 4 ++-- > kernel/sched/fair.c | 57 +++++++++++++++++++++++++++++++++++++--------- > kernel/time/tick-sched.c | 8 +++---- > 3 files changed, 52 insertions(+), 17 deletions(-) > > -- > 1.7.9.5 > > -- > 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/
| |