Comment 11 for bug 549428

So itseems it's some shortage of RAM somewhere:
I joined #ubuntu-kernel:
20:10 < lool> My kernel is doing stuff but I dont know what
20:10 < lool> and my machine is dying under background IO load
20:10 < lool> I tried sudo perf top, iotop, regular top, and can't tell what's
              happening
20:10 < lool> see bug #549428
20:10 < ubot3> Malone bug 549428 in apparmor "Triggers permanent high i/o load
               after upgrade" [Undecided,Fix committed]
               https://launchpad.net/bugs/549428
20:10 < lool> I get this regularly, but not daily
20:11 < lool> I will have to reboot the system pretty soon given that it's
              almost unusable now; anything I can do?
20:12 < lool> I don't know whether that's expected, but cat
              /sys/kernel/debug/dri/64/vma returns
20:12 < lool> cat: /sys/kernel/debug/dri/64/vma: Cannot allocate memory
20:13 < lool> sudo cat i915_ringbuffer_data
20:13 < lool> cat: i915_ringbuffer_data: Ne peut allouer de la mémoire
20:13 < lool> that sounds bad
20:13 < smb> At least like something went crazy requesting memory
20:14 < lool> oddly, meminfo lists plenty of cached stuff
20:14 < lool> Oh I know
20:14 < lool> So I'm using ecryptfs
20:14 < lool> and I use unison in the background
20:14 < lool> Every so many days, this starts happening
20:14 < lool> I bet it's not giving back some memory to the OS
20:14 < lool> smb: How could I track memory down?
20:15 < lool> http://paste.ubuntu.com/418779/ < meminfo
20:15 < lool> Cached: 2492220 kB
20:15 < smb> Maybe one could keep tracking memory allocation while running
20:15 < smb> apparently you cannot even look right now
20:15 < lool> smb: Well my system still runs for some rason
20:15 < lool> reason
20:15 < smb> A high cached value is normal
20:15 < lool> I suspect the background load is swapping
20:16 < lool> Except I dont have any hmm
20:16 < lool> smb: Yes, but I mean this should be reclaimable to allocate memory
20:16 < lool> smb: I would expect that if my kernel used all available mem,
              this value would be small
20:16 < lool> VmallocTotal: 34359738367 kB
20:16 < lool> VmallocChunk: 34359353372 kB
20:17 < lool> that's.... too much
20:17 < lool> I don't have 34 TB of vm
20:17 < lool> Hmm apparently that's normal
20:17 < lool> it matches another host
20:18 < lool> probably some addressable range
20:20 < smb> I would believe so
20:24 < smb> lool, The thing is that you seem to be unable to start new tasks
             which sounds like shortage of allocable memory
20:25 < lool> smb: I can actually start other tasks
20:25 < lool> Could at least
20:25 < lool> smb: I could open an xterm for instance
20:25 < lool> albeit slowly

I suspect it's ecryptfs or drm; drm because it shows up frequently in perf top, and because cat on some /sys/kernel/debug files would fail before reboot and now works fine, but that could be due to memory having been eaten by someone else.
ecryptfs could be related because I see disk activity and because this would explain the delay before this happens; I run unison over a GB of data every 5 minutes, so that would expose a memleak after a while.