We wish to know how long it takes to perform an OOM kill.  A victim may take a long time (or forever) to exit the kernel and die, and the OOM kill code can end up waiting for a long time before it succeeds.

These logs from issue 896805 demonstrate the problem.

<4>[  212.236266] Task <URL: 13> refused to die (killer <URL: 14> nvcsw=1454, nivcsw=3721)
<4>[  213.311265] Task <URL: 13> refused to die (killer powerd:1349:1349, nvcsw=409, nivcsw=375)
<4>[  213.789207] Task <URL: 13> refused to die (killer powerd:1349:1349, nvcsw=472, nivcsw=379)
<4>[  213.890298] Task <URL: 13> refused to die (killer Chrome_SyncThre:2839:1366, nvcsw=521, nivcsw=762)
<4>[  214.728599] Task <URL: 13> refused to die (killer mali-mem-purge:1639:1606, nvcsw=2227, nivcsw=1514)
<4>[  215.158786] Task <URL: 13> refused to die (killer powerd:1349:1349, nvcsw=522, nivcsw=395)
<4>[  215.618208] Task <URL: 13> refused to die (killer powerd:1349:1349, nvcsw=554, nivcsw=404)
<4>[  218.169292] Task ScriptStreamer :5269 refused to die (killer shill:1547:1547, nvcsw=578, nivcsw=1477)
<4>[  218.377301] Task ScriptStreamer :5269 refused to die (killer TaskSchedulerFo:1585:1366, nvcsw=22372, nivcsw=5696)
<4>[  220.225357] Task CompositorTileW:5247 refused to die (killer Compositor:5345:5334, nvcsw=203, nivcsw=151)

The anomaly collector already scans /var/log/messages with a lex-generated scanner, so the overhead of adding more patterns should be low.