Skip to contentSkip to conversation

sched/fair: Move se->vruntime normalization state into struct sched_entity

PATCH Paul E. McKenney 1 participant 2 messages May 24, 2016 – May 25, 2016

lore
Share & tools
lore

Paul E. McKenney

author Tested-by
#0 lore raw
Quoted 8 lines · Peter Zijlstra
Quoted 7 lines · Mike Galbraith
Quoted 5 lines · Mike Galbraith
Quoted 3 lines · Mike Galbraith

Wakees that were not migrated/normalized eat an unwanted min_vruntime, and likely take a size XXL latency hit. Big box running master bled profusely under heavy load until I turned TTWU_QUEUE off.

Quoted 6 lines
Quoted 4 lines

May as well make it official and against master.today. Fly or die little patchlet.

sched/fair: Move se->vruntime normalization state into struct sched_entity

Does this work?

This gets rid of the additional lost wakeups introduced during the merge window, thank you!

The pre-existing low-probability lost wakeups still persist, sad to say Can't have everything, I guess.

Quoted 68 lines
---
 include/linux/sched.h |  1 +
 kernel/sched/core.c   | 18 +++++++++++-------
 2 files changed, 12 insertions(+), 7 deletions(-)
include/linux/sched.h +1 -0
index 1b43b45a22b9..a2001e01b3df 100644
@@ -1534,6 +1534,7 @@ struct task_struct {
        unsigned sched_reset_on_fork:1;
        unsigned sched_contributes_to_load:1;
        unsigned sched_migrated:1;
+       unsigned sched_remote_wakeup:1;
        unsigned :0; /* force alignment to the next boundary */
 
        /* unserialized, strictly 'current' */
kernel/sched/core.c +10 -6
index 404c0784b1fc..7f2cae4620c7 100644
@@ -1768,13 +1768,15 @@ void sched_ttwu_pending(void)
        cookie = lockdep_pin_lock(&rq->lock);
 
        while (llist) {
+               int wake_flags = 0;
+
                p = llist_entry(llist, struct task_struct, wake_entry);
                llist = llist_next(llist);
-               /*
-                * See ttwu_queue(); we only call ttwu_queue_remote() when
-                * its a x-cpu wakeup.
-                */
-               ttwu_do_activate(rq, p, WF_MIGRATED, cookie);
+
+               if (p->sched_remote_wakeup)
+                       wake_flags = WF_MIGRATED;
+
+               ttwu_do_activate(rq, p, wake_flags, cookie);
        }
 
        lockdep_unpin_lock(&rq->lock, cookie);
@@ -1819,10 +1821,12 @@ void scheduler_ipi(void)
        irq_exit();
 }
 
-static void ttwu_queue_remote(struct task_struct *p, int cpu)
+static void ttwu_queue_remote(struct task_struct *p, int cpu, int
 wake_flags)
 {
        struct rq *rq = cpu_rq(cpu);
 
+       p->sched_remote_wakeup = !!(wake_flags & WF_MIGRATED);
+
        if (llist_add(&p->wake_entry, &cpu_rq(cpu)->wake_list)) {
                if (!set_nr_if_polling(rq->idle))
                        smp_send_reschedule(cpu);
kernel/sched/core.c +1 -1
@@ -1869,7 +1873,7 @@ static void ttwu_queue(struct task_struct *p, int
 cpu, int wake_flags)
 #if defined(CONFIG_SMP)
        if (sched_feat(TTWU_QUEUE) && !cpus_share_cache(smp_processor_id(),
 cpu)) {
                sched_clock_cpu(cpu); /* sync clocks x-cpu */
-               ttwu_queue_remote(p, cpu);
+               ttwu_queue_remote(p, cpu, wake_flags);
                return;
        }

#endif

#1 lore raw
Quoted 14 lines · Paul E. McKenney
Quoted 13 lines · Peter Zijlstra
Quoted 11 lines · Mike Galbraith
Quoted 5 lines · Mike Galbraith
Quoted 3 lines · Mike Galbraith

Wakees that were not migrated/normalized eat an unwanted min_vruntime, and likely take a size XXL latency hit. Big box running master bled profusely under heavy load until I turned TTWU_QUEUE off.

May as well make it official and against master.today. Fly or die little patchlet.

sched/fair: Move se->vruntime normalization state into struct sched_entity

Quoted 7 lines
Quoted 1 line

Does this work?

This gets rid of the additional lost wakeups introduced during the merge window, thank you!

The pre-existing low-probability lost wakeups still persist, sad to say Can't have everything, I guess.

However, their behavior has changed. Previously, the TREE03 rcutorture scenario had the most stalls. Now TREE07 appears to be more likely. The corresponding Kconfig fragments are shown below, in case it gives someone ideas about where the problem might be.

My current guess, based on insufficient data, is that TREE07 has about an 80-90% chance of seeing a lost wakeup during a two-hour run.

Thanx, Paul

------------------------------------------------------------------------
TREE03
------------------------------------------------------------------------
CONFIG_SMP=y
CONFIG_NR_CPUS=16
CONFIG_PREEMPT_NONE=n
CONFIG_PREEMPT_VOLUNTARY=n
CONFIG_PREEMPT=y
#CHECK#CONFIG_PREEMPT_RCU=y
CONFIG_HZ_PERIODIC=y
CONFIG_NO_HZ_IDLE=n
CONFIG_NO_HZ_FULL=n
CONFIG_RCU_TRACE=y
CONFIG_HOTPLUG_CPU=y
CONFIG_RCU_FANOUT=2
CONFIG_RCU_FANOUT_LEAF=2
CONFIG_RCU_NOCB_CPU=n
CONFIG_DEBUG_LOCK_ALLOC=n
CONFIG_RCU_BOOST=y
CONFIG_RCU_KTHREAD_PRIO=2
CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
CONFIG_RCU_EXPERT=y

------------------------------------------------------------------------
TREE07
------------------------------------------------------------------------
CONFIG_SMP=y
CONFIG_NR_CPUS=16
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_VOLUNTARY=n
CONFIG_PREEMPT=n
#CHECK#CONFIG_TREE_RCU=y
CONFIG_HZ_PERIODIC=n
CONFIG_NO_HZ_IDLE=n
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=n
CONFIG_NO_HZ_FULL_SYSIDLE=y
CONFIG_RCU_FAST_NO_HZ=n
CONFIG_RCU_TRACE=y
CONFIG_HOTPLUG_CPU=y
CONFIG_RCU_FANOUT=2
CONFIG_RCU_FANOUT_LEAF=2
CONFIG_RCU_NOCB_CPU=n
CONFIG_DEBUG_LOCK_ALLOC=n
CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
CONFIG_RCU_EXPERT=y