linux-kernel - sched: wakeup profile for sd-wake-affine optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <b040c32a0812152301t6718aabbua3820a710801df02@mail.gmail.com>
Date:	Mon, 15 Dec 2008 23:01:02 -0800
From:	Ken Chen <kenchen@...gle.com>
To:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: sched: wakeup profile for sd-wake-affine optimization

Hi,

We continue seeing problems with wake-affine load balance heuristics on our
workloads.  I did some instrumentation on application wake-up profile and I
thought it would be good to share the result with the kernel community.

First attached is a 3D surface plot of wake-up initiator, target, and their
occurrence.  (wakeup-surface.png). x-axis is the source of wakeup initiator
(the one that sends the wakeup event), y-axis is the target of the wakeup
(the one that got woken up).  z-axis is the occurrence count.  From the
graph, it is clear that the distribution of wakeup initiators is non-uniform.
There is clearly one small cluster of sources waking up one small cluster
of targets.  Besides the two peaks in the surface graph, the other area are
not flat either, further indicates non-uniformity in wakeup distribution
profile.

2nd graph is a flattened 3d surface with the same data.  Each line is a
source of wakeup initiator, x-axis is the target and y-axis is number of
wakeup events.  This graph distinctively showed that there is one wakeup
initiator (irq context) wakes up two target threads (tid 6149 and 6191)
while there are no other initiator wakes up these two targets.

With sd-wake-affine, what happened is that these two target threads got
pulled to only *one* cpu due to wakeup initiator are more likely to be
executed only on a small set of CPU in the system.  And there are no other
source to load balance it back and spread these two threads execution on
multiple CPUs.  The end result is that we see idle time as the system
couldn't load balance all runnable threads on all available CPUs.

I was hoping that smart people here on LKML can brainstorm a solution.
My solution earlier was to introduce a sysctl to control sd-wake-affine
behavior, but that requires user to know what their application behavior
is and is not a desirable solution for general usage.

- Ken

Download attachment "wakeup-surface.png" of type "image/png" (7105 bytes)

Download attachment "wakeup-2d.png" of type "image/png" (6662 bytes)