Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
Thank you Bastian for the recommendation to look into the swappiness parameter. I had previously been curious whether I could integrate the *mlock* tool to tell kernel explicitly which processes to not swap out (e.g. olsrd, wpa_supplicant). I also just discovered a Nanostation M mesh node running r38347 which had recently suffered memory exhaustion, although it thankfully remained in a controllable/recoverable state. This device had 3Mbytes of compressed swap available, and I'm quoting relevant portions of dmesg below for the list's reference. It appears that an initial page allocation failure occurred at 315650.43, causing subsequent failures in the mac80211 TX buffer, etc. dmesg shows nothing immediately preceding timestamp 315650.43 to suggest a specific cause. I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. [315650.43] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.43] Call Trace:[8027a0b8] 0x8027a0b8 [315650.43] [8027a0b8] 0x8027a0b8 [315650.43] [800b041c] 0x800b041c [315650.43] [800b2680] 0x800b2680 [315650.43] [800931b4] 0x800931b4 [315650.43] [800d69a4] 0x800d69a4 [315650.43] [8027b574] 0x8027b574 [315650.43] [800d7134] 0x800d7134 [315650.43] [80d2020c] 0x80d2020c [315650.43] [801e8d90] 0x801e8d90 [315650.43] [80d202b8] 0x80d202b8 [315650.43] [80d21608] 0x80d21608 [315650.43] [80de087c] 0x80de087c [315650.43] [800a4d1c] 0x800a4d1c [315650.43] [801f3e1c] 0x801f3e1c [315650.43] [80207648] 0x80207648 [315650.43] [800b2be8] 0x800b2be8 [315650.43] [8020793c] 0x8020793c [315650.43] [800d6790] 0x800d6790 [315650.43] [801ef644] 0x801ef644 [315650.43] [800929c8] 0x800929c8 [315650.43] [80077340] 0x80077340 [315650.43] [8027d8cc] 0x8027d8cc [315650.43] [800955b0] 0x800955b0 [315650.43] [80077468] 0x80077468 [315650.43] [800773f0] 0x800773f0 [315650.43] [800773f0] 0x800773f0 [315650.43] [8008a940] 0x8008a940 [315650.43] [80064b90] 0x80064b90 [315650.43] [8008a8b8] 0x8008a8b8 [315650.43] [80064b80] 0x80064b80 [315650.43] [315650.43] Mem-Info: [315650.43] Normal per-cpu: [315650.43] CPU0: hi:0, btch: 1 usd: 0 [315650.43] active_anon:325 inactive_anon:475 isolated_anon:0 [315650.43] active_file:1421 inactive_file:1233 isolated_file:0 [315650.43] unevictable:0 dirty:0 writeback:0 unstable:0 [315650.43] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315650.43] mapped:574 shmem:48 pagetables:72 bounce:0 [315650.43] Normal free:272kB min:720kB low:900kB high:1080kB active_anon:1300kB inactive_anon:1900kB active_file:5684kB inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no [315650.43] lowmem_reserve[]: 0 0 [315650.43] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB [315650.43] 2715 total pagecache pages [315650.43] 13 pages in swap cache [315650.43] Swap cache stats: add 41, delete 28, find 3/7 [315650.43] Free swap = 3004kB [315650.43] Total swap = 3068kB [315650.43] 8192 pages RAM [315650.43] 876 pages reserved [315650.43] 2389 pages shared [315650.43] 5924 pages non-shared [315650.43] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315650.43] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315650.43] node 0: slabs: 0, objs: 0, free: 0 [315650.70] ieee80211 phy0: failed to reallocate TX buffer [315650.70] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.70] Call Trace:[8027a0b8] 0x8027a0b8 [315650.70] [8027a0b8] 0x8027a0b8 [315650.70] [800b041c] 0x800b041c [315650.70] [800b2680] 0x800b2680 [315650.70] [800d69a4] 0x800d69a4 [315650.70] [8027b574] 0x8027b574 [315650.70] [800d7134] 0x800d7134 [315650.70] [801e8d90] 0x801e8d90 [315650.70] [801a63fc] 0x801a63fc [315650.70] [80d202b8] 0x80d202b8 [315650.70] [8019f544] 0x8019f544 [315650.70] [80d21608] 0x80d21608 [315650.70] [80de087c] 0x80de087c [315650.70] [800a4d1c] 0x800a4d1c [315650.70] [801f3e1c] 0x801f3e1c [315650.70] [80debb94] 0x80debb94 [315650.70] [80207648] 0x80207648 [315650.70] [8020793c] 0x8020793c [315650.70] [80debd58] 0x80debd58 [315650.70] [801ef644] 0x801ef644 [315650.70] [80077340] 0x80077340 [315650.70] [8027d8cc] 0x8027d8cc [315650.70]
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
Hmm, actually I discovered that wpa_supplicant apparently wrote a 240Kbyte dump file on this device, with approximately the same timestamp as when the memory errors started appearing in dmesg. /tmp/wpa_supplicant.1625.11.1384060826.core I've retained the dump file, if anyone perhaps wants it. Likewise, I'd be curious if anyone else has seen such a dump file appear before, as this is my first. (Or at least it is the first where I had a chance to inspect /tmp before rebooting.) On Mon, Nov 11, 2013 at 12:49 PM, Ben West b...@gowasabi.net wrote: Thank you Bastian for the recommendation to look into the swappiness parameter. I had previously been curious whether I could integrate the *mlock* tool to tell kernel explicitly which processes to not swap out (e.g. olsrd, wpa_supplicant). I also just discovered a Nanostation M mesh node running r38347 which had recently suffered memory exhaustion, although it thankfully remained in a controllable/recoverable state. This device had 3Mbytes of compressed swap available, and I'm quoting relevant portions of dmesg below for the list's reference. It appears that an initial page allocation failure occurred at 315650.43, causing subsequent failures in the mac80211 TX buffer, etc. dmesg shows nothing immediately preceding timestamp 315650.43 to suggest a specific cause. I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. [315650.43] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.43] Call Trace:[8027a0b8] 0x8027a0b8 [315650.43] [8027a0b8] 0x8027a0b8 [315650.43] [800b041c] 0x800b041c [315650.43] [800b2680] 0x800b2680 [315650.43] [800931b4] 0x800931b4 [315650.43] [800d69a4] 0x800d69a4 [315650.43] [8027b574] 0x8027b574 [315650.43] [800d7134] 0x800d7134 [315650.43] [80d2020c] 0x80d2020c [315650.43] [801e8d90] 0x801e8d90 [315650.43] [80d202b8] 0x80d202b8 [315650.43] [80d21608] 0x80d21608 [315650.43] [80de087c] 0x80de087c [315650.43] [800a4d1c] 0x800a4d1c [315650.43] [801f3e1c] 0x801f3e1c [315650.43] [80207648] 0x80207648 [315650.43] [800b2be8] 0x800b2be8 [315650.43] [8020793c] 0x8020793c [315650.43] [800d6790] 0x800d6790 [315650.43] [801ef644] 0x801ef644 [315650.43] [800929c8] 0x800929c8 [315650.43] [80077340] 0x80077340 [315650.43] [8027d8cc] 0x8027d8cc [315650.43] [800955b0] 0x800955b0 [315650.43] [80077468] 0x80077468 [315650.43] [800773f0] 0x800773f0 [315650.43] [800773f0] 0x800773f0 [315650.43] [8008a940] 0x8008a940 [315650.43] [80064b90] 0x80064b90 [315650.43] [8008a8b8] 0x8008a8b8 [315650.43] [80064b80] 0x80064b80 [315650.43] [315650.43] Mem-Info: [315650.43] Normal per-cpu: [315650.43] CPU0: hi:0, btch: 1 usd: 0 [315650.43] active_anon:325 inactive_anon:475 isolated_anon:0 [315650.43] active_file:1421 inactive_file:1233 isolated_file:0 [315650.43] unevictable:0 dirty:0 writeback:0 unstable:0 [315650.43] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315650.43] mapped:574 shmem:48 pagetables:72 bounce:0 [315650.43] Normal free:272kB min:720kB low:900kB high:1080kB active_anon:1300kB inactive_anon:1900kB active_file:5684kB inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no [315650.43] lowmem_reserve[]: 0 0 [315650.43] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB [315650.43] 2715 total pagecache pages [315650.43] 13 pages in swap cache [315650.43] Swap cache stats: add 41, delete 28, find 3/7 [315650.43] Free swap = 3004kB [315650.43] Total swap = 3068kB [315650.43] 8192 pages RAM [315650.43] 876 pages reserved [315650.43] 2389 pages shared [315650.43] 5924 pages non-shared [315650.43] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315650.43] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315650.43] node 0: slabs: 0, objs: 0, free: 0 [315650.70] ieee80211 phy0: failed to reallocate TX buffer [315650.70] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.70] Call Trace:[8027a0b8] 0x8027a0b8 [315650.70] [8027a0b8] 0x8027a0b8 [315650.70] [800b041c] 0x800b041c [315650.70] [800b2680] 0x800b2680 [315650.70] [800d69a4] 0x800d69a4 [315650.70]
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
I can take a look at it and see if there is anything interesting, I might be able to get it disassembled if its any sort of executable. It might just be an array or something though. On Mon, Nov 11, 2013 at 12:56 PM, Ben West b...@gowasabi.net wrote: Hmm, actually I discovered that wpa_supplicant apparently wrote a 240Kbyte dump file on this device, with approximately the same timestamp as when the memory errors started appearing in dmesg. /tmp/wpa_supplicant.1625.11.1384060826.core I've retained the dump file, if anyone perhaps wants it. Likewise, I'd be curious if anyone else has seen such a dump file appear before, as this is my first. (Or at least it is the first where I had a chance to inspect /tmp before rebooting.) On Mon, Nov 11, 2013 at 12:49 PM, Ben West b...@gowasabi.net wrote: Thank you Bastian for the recommendation to look into the swappiness parameter. I had previously been curious whether I could integrate the *mlock* tool to tell kernel explicitly which processes to not swap out (e.g. olsrd, wpa_supplicant). I also just discovered a Nanostation M mesh node running r38347 which had recently suffered memory exhaustion, although it thankfully remained in a controllable/recoverable state. This device had 3Mbytes of compressed swap available, and I'm quoting relevant portions of dmesg below for the list's reference. It appears that an initial page allocation failure occurred at 315650.43, causing subsequent failures in the mac80211 TX buffer, etc. dmesg shows nothing immediately preceding timestamp 315650.43 to suggest a specific cause. I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. [315650.43] ksoftirqd/0: page allocation failure: order:0, mode:0x4020 [315650.43] Call Trace:[8027a0b8] 0x8027a0b8 [315650.43] [8027a0b8] 0x8027a0b8 [315650.43] [800b041c] 0x800b041c [315650.43] [800b2680] 0x800b2680 [315650.43] [800931b4] 0x800931b4 [315650.43] [800d69a4] 0x800d69a4 [315650.43] [8027b574] 0x8027b574 [315650.43] [800d7134] 0x800d7134 [315650.43] [80d2020c] 0x80d2020c [315650.43] [801e8d90] 0x801e8d90 [315650.43] [80d202b8] 0x80d202b8 [315650.43] [80d21608] 0x80d21608 [315650.43] [80de087c] 0x80de087c [315650.43] [800a4d1c] 0x800a4d1c [315650.43] [801f3e1c] 0x801f3e1c [315650.43] [80207648] 0x80207648 [315650.43] [800b2be8] 0x800b2be8 [315650.43] [8020793c] 0x8020793c [315650.43] [800d6790] 0x800d6790 [315650.43] [801ef644] 0x801ef644 [315650.43] [800929c8] 0x800929c8 [315650.43] [80077340] 0x80077340 [315650.43] [8027d8cc] 0x8027d8cc [315650.43] [800955b0] 0x800955b0 [315650.43] [80077468] 0x80077468 [315650.43] [800773f0] 0x800773f0 [315650.43] [800773f0] 0x800773f0 [315650.43] [8008a940] 0x8008a940 [315650.43] [80064b90] 0x80064b90 [315650.43] [8008a8b8] 0x8008a8b8 [315650.43] [80064b80] 0x80064b80 [315650.43] [315650.43] Mem-Info: [315650.43] Normal per-cpu: [315650.43] CPU0: hi:0, btch: 1 usd: 0 [315650.43] active_anon:325 inactive_anon:475 isolated_anon:0 [315650.43] active_file:1421 inactive_file:1233 isolated_file:0 [315650.43] unevictable:0 dirty:0 writeback:0 unstable:0 [315650.43] free:68 slab_reclaimable:385 slab_unreclaimable:2131 [315650.43] mapped:574 shmem:48 pagetables:72 bounce:0 [315650.43] Normal free:272kB min:720kB low:900kB high:1080kB active_anon:1300kB inactive_anon:1900kB active_file:5684kB inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no [315650.43] lowmem_reserve[]: 0 0 [315650.43] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB [315650.43] 2715 total pagecache pages [315650.43] 13 pages in swap cache [315650.43] Swap cache stats: add 41, delete 28, find 3/7 [315650.43] Free swap = 3004kB [315650.43] Total swap = 3068kB [315650.43] 8192 pages RAM [315650.43] 876 pages reserved [315650.43] 2389 pages shared [315650.43] 5924 pages non-shared [315650.43] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [315650.43] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 [315650.43] node 0: slabs: 0, objs: 0, free: 0 [315650.70] ieee80211 phy0: failed to reallocate TX buffer [315650.70] ksoftirqd/0: page
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
* Ben West b...@gowasabi.net [11.11.2013 20:36]: I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. for routers in production i prefer setting /proc/sys/vm/panic_on_oom = 2 /proc/sys/kernel/panic = 10 also if you like /proc/sys/kernel/panic_on_oops = 1 the crashdump itself is useless without debugging symbols. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
It might mappable against the driver binary or kernel image. Kind of depends on what it is in it. On Mon, Nov 11, 2013 at 1:39 PM, Bastian Bittorf bitt...@bluebottle.comwrote: * Ben West b...@gowasabi.net [11.11.2013 20:36]: I am assuming incidents like these are occurring due to an ill-behaved process (or processes) attempting to allocate several MBytes for itself, failing that, and also causing memory errors for random resident processes in consequence. The only recovery I know for these incidents is to just reboot. for routers in production i prefer setting /proc/sys/vm/panic_on_oom = 2 /proc/sys/kernel/panic = 10 also if you like /proc/sys/kernel/panic_on_oops = 1 the crashdump itself is useless without debugging symbols. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
* Ben West b...@gowasabi.net [09.11.2013 19:22]: anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then we have zram active on all nodes but tweaked the 'swappiness' value to 0 - the default is 65. the higher the number, the more likely the kernel swaps out. if set to 0 zram is only used if the is no other possibility. ofcourse: if swapping begins, the box freezes for some seconds but it does not die. the kernel likes to swap out processes which are not in use, e.g. uhttpd or dropbear. olsrd or other active processes are very unlikely to be swapped - the kernel is smart somehow 8-) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
Hi Ben, Thanks for the feedback. That's strange, although has logic. Even more strage is that your device has 32MB of Ram so it should be able to be handling things well. Can you compile the trunk (Barrier Breaker) and test with it on the same device to find out if it will behavior the same way ? Perhaps the problem is somewhere else or something specific to the way zram works on kernel 3.3 like Hauke mentioned in a earlier email. Regards, Fernando On 8 November 2013 05:40, Ben West b...@gowasabi.net wrote: As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
On 8 Nov 2013 00:41, Ben West b...@gowasabi.net wrote: As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). Have you tried turning down swappiness? The default setting likes to swap things out quicker then you would think. I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
