On Sat, Aug 31, 2013 at 05:06:42PM -0700, Greg Thelen wrote: > A memory cgroup with (1) multiple threshold notifications and (2) at > least one threshold >=2G was not reliable. Specifically the > notifications would either not fire or would not fire in the proper > order. > > The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit > thresholds in sorted order. mem_cgroup_usage_register_event() sorts > them with compare_thresholds(), which returns the difference of two 64 > bit thresholds as an int. If the difference is positive but has > bit[31] set, then sort() treats the difference as negative and breaks > sort order. > > This fix compares the two arbitrary 64 bit thresholds returning the > classic -1, 0, 1 result. > > The test below sets two notifications (at 0x1000 and 0x81001000): > cd /sys/fs/cgroup/memory > mkdir x > for x in 4096 2164264960; do > cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" & > done > echo $$ > x/cgroup.procs > anon_leaker 500M > > v3.11-rc7 fails to signal the 4096 event listener: > Leaking... > Done leaking pages. > > Patched v3.11-rc7 properly notifies: > Leaking... > 4096 listener:2013:8:31:14:13:36 > Done leaking pages. > > The fixed bug is old. It appears to date back to the introduction of > memcg threshold notifications in v2.6.34-rc1-116-g2e72b6347c94 "memcg: > implement memory thresholds" > > Signed-off-by: Greg Thelen <gthelen@xxxxxxxxxx> Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
