Re: [SHR-U] WiFi-related memory leak
Denis Shulyaka writes: > I have no idea why it decreased. I guess kernel unloads some parts of > executable that are not executed ATM. Ah that is true, read-only mappings do not need to be kept in memory. > BTW, what kind of WiFi authentication and encryption do you use? I use > WPA and TKIP, may be I should try something else? No encryption in this case. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
2010/2/24 Timo Juhani Lindfors : > Hmm. The memory usage of frameworkd actually decreased during the test: > How can this happen? ;) > Same for Xorg too: > and hal: I have no idea why it decreased. I guess kernel unloads some parts of executable that are not executed ATM. > (Why is it running as sshd user btw?!) I don't know, isn't it default in SHR? > I have never used slabtop before. Here when wifi is connected it > displays > 38 38 100% 4.00K 38 1 152K size-4096 So it's just 152K. In my case it's 40-50K and counting. BTW, what kind of WiFi authentication and encryption do you use? I use WPA and TKIP, may be I should try something else? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
Denis Shulyaka writes: > Here it is. Without swap and midori this time: > ftp://shulyaka.org.ru/pub/memlog2.tar.bz2 Hmm. The memory usage of frameworkd actually decreased during the test: $ grep frameworkd ps* ps.17:57:32:root 1219 46.6 16.4 32368 19876 ?Ss 17:31 12:15 python /usr/bin/frameworkd ps.18:02:34:root 1219 39.1 16.4 32368 19876 ?Ss 17:31 12:16 python /usr/bin/frameworkd ps.18:07:36:root 1219 34.0 16.2 32368 19628 ?Ss 17:31 12:21 python /usr/bin/frameworkd ps.18:12:38:root 1219 29.9 16.1 32368 19500 ?Ss 17:31 12:22 python /usr/bin/frameworkd ps.18:17:40:root 1219 26.6 15.5 32368 18780 ?Ss 17:31 12:22 python /usr/bin/frameworkd ps.18:22:42:root 1219 24.0 15.4 32368 18676 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:27:44:root 1219 21.9 14.8 32368 17964 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:32:46:root 1219 20.1 14.5 32368 17592 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:37:50:root 1219 18.6 14.3 32368 17376 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:42:54:root 1219 17.2 14.0 32368 17044 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:48:00:root 1219 16.1 13.7 32368 16668 ?Ss 17:31 12:23 python /usr/bin/frameworkd ps.18:53:06:root 1219 15.1 13.5 32368 16384 ?Ds 17:31 12:24 python /usr/bin/frameworkd ps.18:58:33:root 1219 14.1 13.0 32368 15812 ?Ss 17:31 12:25 python /usr/bin/frameworkd ps.19:22:18:root 1219 13.5 13.5 32368 16356 ?Rs 17:31 15:02 python /usr/bin/frameworkd ps.19:27:22:root 1219 17.2 13.5 32368 16356 ?Rs 17:31 20:00 python /usr/bin/frameworkd ps.19:32:24:root 1219 20.6 13.5 32368 16356 ?Rs 17:31 24:58 python /usr/bin/frameworkd ps.19:37:26:root 1219 23.6 13.5 32368 16356 ?Rs 17:31 29:52 python /usr/bin/frameworkd ps.19:42:30:root 1219 26.5 13.5 32368 16356 ?Rs 17:31 34:51 python /usr/bin/frameworkd ps.19:47:47:root 1219 29.2 13.5 32368 16356 ?Rs 17:31 39:53 python /usr/bin/frameworkd ps.19:53:12:root 1219 31.0 13.5 32368 16356 ?Rs 17:31 44:01 python /usr/bin/frameworkd How can this happen? ;) Same for Xorg too: $ grep "_ /usr/bin/Xorg" ps* ps.17:57:32:root 1203 3.9 5.4 10780 6592 tty1 S The most interesting line in slabtop was: > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 12278 12278 100%4.00K 122781 49112K size-4096 > > It was counting all the time the test was run. Don't know what it means > though. I have never used slabtop before. Here when wifi is connected it displays Active / Total Objects (% used): 22154 / 38108 (58.1%) Active / Total Slabs (% used) : 1356 / 1356 (100.0%) Active / Total Caches (% used) : 68 / 117 (58.1%) Active / Total Size (% used) : 3416.10K / 5276.42K (64.7%) Minimum / Average / Maximum Object : 0.01K / 0.14K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 8496 1743 20%0.05K118 72 472K buffer_head 5520 1830 33%0.12K184 30 736K dentry 3864 3824 98%0.04K 46 84 184K sysfs_dir_cache 3390 3337 98%0.03K 30 113 120K size-32 2944 2570 87%0.08K 64 46 256K vm_area_struct 2484976 39%0.41K2769 1104K ext3_inode_cache 1547 1136 73%0.28K119 13 476K radix_tree_node 1356815 60%0.01K 4 33916K anon_vma 1298 1117 86%0.06K 22 5988K size-64 1140900 78%0.12K 38 30 152K filp 480457 95%0.09K 12 4048K size-96 430425 98%0.38K 43 10 172K shmem_inode_cache 384274 71%0.31K 32 12 128K proc_inode_cache 360240 66%0.09K 9 4036K cred_jar 330310 93%0.12K 11 3044K size-128 320282 88%0.50K 408 160K size-512 254 2 0%0.01K 1 254 4K revoke_table 234209 89%0.14K 9 2636K idr_layer_cache 203 1 0%0.02K 1 203 4K ip_fib_alias 203 5 2%0.02K 1 203 4K tcp_bind_bucket 203 2 0%0.02K 1 203 4K fasync_cache 180177 98%0.25K 12 1548K size-256 169141 83%0.29K 13 1352K inode_cache 140 80 57%0.19K 7 2028K skbuff_head_cache 120116 96%0.09K 3 4012K kmem_cache 120 98 81%1.00K 304 120K size-1024 118118 100%0.06K 2 59 8K pid 113 95 84%0.03K
Re: [SHR-U] WiFi-related memory leak
2010/2/21 Timo Juhani Lindfors : > Can you try the same test again without swap? Here it is. Without swap and midori this time: ftp://shulyaka.org.ru/pub/memlog2.tar.bz2 The phone survived for 2 hours this time. I guess it could live a little longer without transmission-daemon. Xorg was killed at about 19:25. I'm not sure about what happened with the script but id didn't take logs for 25 minutes between 18:58 and 19:22. It's the time when transmission-daemon was killed. The most interesting line in slabtop was: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 12278 12278 100%4.00K 122781 49112K size-4096 It was counting all the time the test was run. Don't know what it means though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
Bastian Muck writes: > I know, I can't help that much, but I am sure that midori is the > problem. I often hear music with vagalume over wlan and it is no > problem to hear 3 or 4 hours. But if I use Midori then after 10 > minutes (and sometimes less) the system hangs because of no ram. You might want to free some RAM by using more light-weight programs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.02.2010 10:37, schrieb Timo Juhani Lindfors: > Denis Shulyaka writes: >> It writes output of `ps auxf`, `free` and `df -h` to a corresponding >> file every 5 minutes. > > Hmm, you are using swap. I do not know how to see how many bytes each > process has in swap. This would let us see which process is the one > whose memory usage steadily increases. Now we only see that RSS > (number of bytes each process has in RAM) decreases when the bytes are > moved to swap. > > Can you try the same test again without swap? > I know, I can't help that much, but I am sure that midori is the problem. I often hear music with vagalume over wlan and it is no problem to hear 3 or 4 hours. But if I use Midori then after 10 minutes (and sometimes less) the system hangs because of no ram. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLgs/OlYiDScJJ+7QRAqSnAJ40A3/O51VvE/sRaIc5Rs1Y5NeygACeJ3mR dSLOnSBG6CQRZJNRfs8J7+k= =nSNz -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
Denis Shulyaka writes: > It writes output of `ps auxf`, `free` and `df -h` to a corresponding > file every 5 minutes. Hmm, you are using swap. I do not know how to see how many bytes each process has in swap. This would let us see which process is the one whose memory usage steadily increases. Now we only see that RSS (number of bytes each process has in RAM) decreases when the bytes are moved to swap. Can you try the same test again without swap? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
> What additional info I can gather? Use slabtop to monitor kernel memory pools. It may be interresting. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
2010/2/19 Denis Shulyaka : > I'll do some logging of `ps auxf`, `free` and `df -h` every 5 minutes. OK, I did some tests today, here are the logs: ftp://shulyaka.org.ru/pub/memlog.tar.bz2 I have rebooted the phone to get clear results, started WiFi, Midori and transmission-daemon and run the following script: #!/bin/bash while true; do STAMP=`date +%H:%M:%S` ps axuf > ps.$STAMP free > free.$STAMP df -h > df.$STAMP sleep 300 done It writes output of `ps auxf`, `free` and `df -h` to a corresponding file every 5 minutes. The phone could survive for 4 hours. When I look at the phone after about 3 hrs and 45 min the Xorg (along with vala-terminal and my script) was already killed (the last log entry was at 3:40). However I still was able to ssh into the phone and get some final data manually (named *.last). On the phone screen I saw text console with following messages: [15237.185000] Out of memory: kill process 1409 (screen) score 188 or a child [15237.185000] Killed process 1442 (sh) [15237.27] Out of memory: kill process 1215 (batget) score 166 or a child [15237.275000] Killed process 1215 (batget) [15238.045000] Out of memory: kill process 1409 (screen) score 124 or a child [15238.05] Killed process 1409 (screen) [15238.22] Out of memory: kill process 1473 (udhcpc) score 118 or a child [15238.225000] Killed process 1473 (udhcpc) [15238.355000] Out of memory: kill process 1445 (wpa_supplicant) score 106 or a child [15238.36] Killed process 1445 (wpa_supplicant) [15239.005000] Out of memory: kill process 2393 (bash) score 98 or a child [15239.01] Killed process 2405 (bash) [16042.17] Out of memory: kill process 2391 (sshd) score 89 or a child [16042.17] Killed process 2393 (bash) [16068.555000] Out of memory: kill process 1083 (sshd) score 56 or a child [16068.555000] Killed process 1083 (sshd) What additional info I can gather? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
2010/2/19 Timo Juhani Lindfors : > Never heard of such a problem. Can you make it happen again? Write a > cron job that logs the output of "ps axuf" to file every 30 minutes > for example. This makes it easy to see if some process is consuming > more and more memory. Yes, it happens every time and much faster than the whole night. I'll do some logging of `ps auxf`, `free` and `df -h` every 5 minutes. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
On Fri, 2010-02-19 at 09:42 +0100, omcomali@porcupinefactory.org wrote: > On Thu, 18 Feb 2010 16:18:32 -0800 (PST) > vancel35 wrote: > > > > > I don't know if what I saw was the same problem, but I left mine on my wifi > > ovenight and when I woke up, it wasn't responding very quickly, but as far > > as I know, nothing had been killed. > > > > I didn't even think about the Wifi being the problem. If it's data-related, > > I probably didn't have enough data passing to cause a problem. > > > > -Laura > > I've had something similar, compiling a big project on the Freerunner with > swap enabled, wifi on. > Before I started, some RAM was free, after it finished (about 6h), and I > closed all programs to match the previous state, the system was much less > responsive, RAM was nearly full and 50MB of swap was used. All programs > seemed to have normal reserved memory footprints. > > The above details are not to be trusted, I could have overlooked something > important. > > Maybe it has something to do with memory fragmentation? Or maybe it's > sd-related? > > Cheers, > rhn > There was a report a while back of logs (which are on a tmpfs and therefore subtract from memory) filling up and causing problems. When on wifi is the FR generating lots of messages? What does "free" and "df -h" report? BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
On Thu, 18 Feb 2010 16:18:32 -0800 (PST) vancel35 wrote: > > I don't know if what I saw was the same problem, but I left mine on my wifi > ovenight and when I woke up, it wasn't responding very quickly, but as far > as I know, nothing had been killed. > > I didn't even think about the Wifi being the problem. If it's data-related, > I probably didn't have enough data passing to cause a problem. > > -Laura I've had something similar, compiling a big project on the Freerunner with swap enabled, wifi on. Before I started, some RAM was free, after it finished (about 6h), and I closed all programs to match the previous state, the system was much less responsive, RAM was nearly full and 50MB of swap was used. All programs seemed to have normal reserved memory footprints. The above details are not to be trusted, I could have overlooked something important. Maybe it has something to do with memory fragmentation? Or maybe it's sd-related? Cheers, rhn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
Denis Shulyaka writes: > Is it a known problem, or I have unique combination of AP software and > FR settings? Never heard of such a problem. Can you make it happen again? Write a cron job that logs the output of "ps axuf" to file every 30 minutes for example. This makes it easy to see if some process is consuming more and more memory. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] WiFi-related memory leak
I don't know if what I saw was the same problem, but I left mine on my wifi ovenight and when I woke up, it wasn't responding very quickly, but as far as I know, nothing had been killed. I didn't even think about the Wifi being the problem. If it's data-related, I probably didn't have enough data passing to cause a problem. -Laura -- View this message in context: http://n2.nabble.com/SHR-U-WiFi-related-memory-leak-tp4595250p4595313.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-U] WiFi-related memory leak
Hi! I'm using the latest SHR unstable. I experience some problems with WiFi. When I enable WiFi and connect to an AP, it works well for about half an hour. Then all the applications begin to respond more and more slowly, and then kernel starts killing everything until it kills wpa_supplicant or Xorg. Now I can't use my freerunner for downloading torrents with transmission-daemon over night any more) Is it a known problem, or I have unique combination of AP software and FR settings? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
