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. -- Triggers permanent high i/o load after upgrade https://bugs.launchpad.net/bugs/549428 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs