Messages in this thread | | | Subject | Re: [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression | From | Mike Galbraith <> | Date | Mon, 11 Sep 2017 04:55:24 +0200 |
| |
On Sun, 2017-09-10 at 09:53 -0700, Joel Fernandes wrote: > > Anyone know what in the netperf test triggers use of the sync flag?
homer:..kernel/linux-master # git grep wake_up_interruptible_sync_poll net net/core/sock.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI | net/core/sock.c: wake_up_interruptible_sync_poll(&wq->wait, POLLOUT | net/sctp/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | net/smc/smc_rx.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI | net/tipc/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLOUT | net/tipc/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | net/unix/af_unix.c: wake_up_interruptible_sync_poll(&wq->wait, net/unix/af_unix.c: wake_up_interruptible_sync_poll(&u->peer_wait,
The same as metric tons of other stuff.
Once upon a time, we had avg_overlap to help decide whether to wake core affine or not, on top of the wake_affine() imbalance constraint, but instrumentation showed it to be too error prone, so it had to die. These days, an affine wakeup generally means cache affine, and the sync hint gives you a wee bit more chance of migration near to tasty hot data being approved.
The sync hint was born back in the bad old days, when communicating tasks not sharing L2 may as well have been talking over two tin cans and a limp string. These days, things are oodles better, but truly synchronous stuff could still benefit from core affinity (up to hugely for very fast/light stuff) if it weren't for all the caveats that can lead to tossing concurrency opportunities out the window.
-Mike
| |