| 00:09.07 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.142) |
| 00:13.13 | *** join/#maemo-ssu Sc0rpius (~naikel@190.79.197.57) |
| 00:36.48 | *** join/#maemo-ssu ron0062000 (~ron006200@cpe-72-181-242-49.tx.res.rr.com) |
| 01:16.33 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.142) |
| 01:45.31 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.142) |
| 02:19.11 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.138) |
| 03:02.26 | *** join/#maemo-ssu dhbiker (~dhbiker@193.2.218.150) |
| 03:26.10 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 04:04.12 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:42.35 | Sc0rpius | heh |
| 04:46.32 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 05:40.55 | *** join/#maemo-ssu chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 07:43.58 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 07:51.52 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 08:08.46 | *** join/#maemo-ssu Milhouse (~irc_milho@Maemo/community/contributor/Milhouse) |
| 08:20.45 | freemangordon | idle wonders why hildon-status-menu needs 6MB of heap |
| 08:25.01 | jon_y | freemangordon: reserved in case it ever needs it without needing to call malloc :) |
| 08:25.49 | freemangordon | jon_y: well, all bins started as .launchers use enormous amounts of heap |
| 08:25.58 | freemangordon | that could be normal, but still |
| 08:26.31 | freemangordon | I still don;t know what that maemo-launcher does :( |
| 08:31.13 | jon_y | it could do worst if you have read thedailyWTF |
| 08:54.36 | kerio | freemangordon: they inherit gtk from maemo-launcher |
| 08:54.43 | kerio | so it doesn't need to be loaded again |
| 08:55.20 | freemangordon | kerio: I understand what maemo-launcher/invoker does with gtk and why |
| 08:56.04 | freemangordon | the point is that every .launcher uses a pile of heap |
| 08:56.16 | freemangordon | which should not be the case |
| 08:58.10 | freemangordon | those ^^^ use at least 4MB, which makes no sense |
| 08:58.31 | freemangordon | esp for hildon-status-menu |
| 08:59.34 | freemangordon | those 7-8 launcher programs use about 40-50 MB of heap, which is instane. Even if it is swapped |
| 08:59.45 | freemangordon | *insane |
| 09:00.09 | kerio | what does that heap contain, i wonder |
| 09:00.29 | freemangordon | NFC how to check it |
| 09:00.42 | kerio | gdb :D |
| 09:00.50 | kerio | or the source code |
| 09:00.56 | freemangordon | kerio: would you check heap size on your device? |
| 09:01.02 | freemangordon | for hildon-status-menu |
| 09:01.06 | kerio | it's just maemo-invoker or something |
| 09:01.10 | kerio | freemangordon: sure, how do i check? |
| 09:01.21 | freemangordon | in/proc/../smaps |
| 09:01.24 | kerio | also, which status-menu? :) |
| 09:01.30 | freemangordon | ps| grep hildon-status-menu |
| 09:01.37 | freemangordon | the second one is yours ;) |
| 09:01.41 | freemangordon | pid |
| 09:01.58 | kerio | so the one under maemo-launcher? |
| 09:02.04 | kerio | that's the real one i think |
| 09:02.10 | freemangordon | yep |
| 09:02.16 | freemangordon | you'll get 2 pids |
| 09:02.32 | freemangordon | second one is what we need |
| 09:02.35 | kerio | holy shit smaps is huge |
| 09:02.42 | freemangordon | yes, it is |
| 09:02.53 | kerio | wat do |
| 09:03.03 | freemangordon | grep -A 9 heap /proc/.../smaps |
| 09:03.23 | kerio | k |
| 09:03.29 | kerio | what do you need? |
| 09:03.43 | freemangordon | Size: |
| 09:03.49 | kerio | oh |
| 09:03.52 | kerio | 2984kB |
| 09:04.05 | freemangordon | makes no sense |
| 09:04.14 | freemangordon | what is your uptime? |
| 09:04.17 | kerio | with pali's battery applet, cpumem-applet, flashlight, simple-brightness-applet and forcerotation |
| 09:04.27 | kerio | 1 day 10:25 |
| 09:04.47 | freemangordon | Size: 5780 kB |
| 09:04.49 | kerio | hold on, did i boot at 11.30 pm then? :O |
| 09:04.53 | kerio | why the hell did i do that |
| 09:05.02 | kerio | oh right, charger confusion |
| 09:05.15 | freemangordon | with flashlight and 2g/3g selection applet |
| 09:05.24 | kerio | oh, i've got 2g/3g too |
| 09:05.37 | kerio | freemangordon: uptime? |
| 09:05.50 | freemangordon | 1d 15h |
| 09:06.01 | kerio | i'll report back in 5 hours then :D |
| 09:06.18 | freemangordon | but,but,... thats crazy! |
| 09:06.31 | freemangordon | well, I have fmms too |
| 09:06.49 | freemangordon | which I think puts status menu applet too |
| 09:07.12 | freemangordon | but again, I can't see a simple reason for such heap usage |
| 09:07.24 | freemangordon | and it is the same for all .launcer processes |
| 09:07.34 | freemangordon | *.launcher |
| 09:08.16 | freemangordon | thats fishy |
| 09:37.40 | freemangordon | hmm, it is not .launcher thingie, if compiled as a simple binary, hildon-status menu still uses 4952 kB |
| 09:39.35 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 09:52.29 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2822F.dip0.t-ipconnect.de) |
| 09:53.33 | freemangordon | hmm, removing rtcom-notification-ui.desktop reduces heap usage by 3MB. WTF?!? |
| 09:56.20 | freemangordon | removing rtcom-presence-ui.desktop saves 1MB more |
| 09:56.41 | kerio | neat! |
| 09:57.05 | kerio | otoh, without the notification ui, you won't get notifications |
| 09:57.58 | freemangordon | I know, I was trying to find who uses such amount of memory |
| 10:00.59 | kerio | hahaha, "Some of the more obscure uses of pivot_root() may quickly lead to insanity." |
| 10:01.04 | kerio | in the pivot_root(2) manpage |
| 10:01.05 | *** join/#maemo-ssu M4rtinK (~M4rtinK@46.227.13.46) |
| 10:01.09 | kerio | in the BUGS section |
| 10:26.53 | *** join/#maemo-ssu iDont (~iDont@dhcp-077-250-143-002.chello.nl) |
| 10:41.19 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2822F.dip0.t-ipconnect.de) |
| 10:53.49 | freemangordon | The fuck, osso-abook-home-applet is using 2100 KB |
| 10:54.06 | jon_y | the address book? |
| 10:54.19 | freemangordon | no, home contact widget |
| 10:54.38 | jon_y | huh, no idea why a link would use that much mem |
| 10:55.03 | freemangordon | well, it uses osso-abook library |
| 10:55.35 | freemangordon | and I am starting to have the feeleing adress book is kept in memory for every osso-abook consumer |
| 10:55.44 | freemangordon | which would be insane |
| 10:55.54 | jon_y | a seperate copy for every consumer? :) |
| 10:56.03 | freemangordon | but so far it seems that is the case |
| 10:56.13 | freemangordon | well, not copy, but something like that |
| 10:56.20 | freemangordon | cache or who knows what |
| 10:56.44 | freemangordon | as osso-abook-home-applet is 21k binary, which does not do much |
| 10:56.47 | ShadowJK | silly coders thinking it'll be faster to load from swap than load from onenand ;) |
| 10:57.11 | freemangordon | ShadowJK: this is heap |
| 10:57.12 | jon_y | ShadowJK: nah their test case was a clean n900 |
| 10:57.15 | freemangordon | 2100K |
| 10:57.26 | ShadowJK | locked in ram? |
| 10:57.34 | freemangordon | does not matter |
| 10:57.41 | jon_y | malloc(n*sizeof(entry)) |
| 10:57.49 | freemangordon | this is mallocked |
| 10:57.54 | freemangordon | *malloced |
| 10:58.33 | ShadowJK | so brk area? |
| 10:58.36 | freemangordon | makes no difference if it is locked in ram or swapped, usig 2MB just to show avatar on desktop is insane |
| 10:58.47 | jon_y | let me guess, osso-abook-home-applet is non-free |
| 10:58.54 | freemangordon | you win |
| 10:58.59 | jon_y | :) |
| 10:59.04 | freemangordon | the same for osso-abook |
| 10:59.16 | jon_y | valgrind will be grinding |
| 10:59.23 | ShadowJK | Yeah I just mean if they preloaded something they were silly thinking loading it from swap would be faster :) |
| 10:59.33 | jon_y | too bad they don't put debug symbols anywhere |
| 10:59.45 | freemangordon | ShadowJK: look backscroll for hildon-status-menu heap usage |
| 11:00.01 | freemangordon | woth and without rtcom-... plugins |
| 11:00.04 | freemangordon | *with |
| 11:00.14 | freemangordon | and those use osso-abook too |
| 11:01.03 | jon_y | so how much mem can I save if I redid the N900 UI with a basic X window without any themes? :) |
| 11:01.46 | freemangordon | so it is either osso-abook or underlying database |
| 11:01.50 | ShadowJK | hm, my hildon-status menu has 66M vmdata :) |
| 11:02.17 | jon_y | yep me too, crazy huge for some reason |
| 11:02.21 | freemangordon | jon_y: who know, 40-60 MB maybe |
| 11:02.48 | jon_y | sweet, an address book list that is an actual list UI element :) |
| 11:03.29 | kerio | ShadowJK: mtdswap |
| 11:03.30 | freemangordon | jon_y: not sure I got your question, but I suspect that database is cached in memory for every process using it |
| 11:03.30 | jon_y | it would look like Win3.11, but it would save memory |
| 11:03.34 | kerio | how do you feel about it? |
| 11:04.08 | freemangordon | which is insane, given there is backend for that purpose |
| 11:04.09 | jon_y | freemangordon: I mean redo the UI portion with a minimalist rewrite and got rid Nokia stuff |
| 11:04.22 | ShadowJK | At the time I still had interest in harmatten and was going to read the sources for it, there were no sources |
| 11:04.22 | freemangordon | jon_y: we cannot get rid of address book |
| 11:04.38 | freemangordon | osso-abook? |
| 11:05.08 | jon_y | actually, I don't know too much of the backend, so I'm likely sprouting nonsense |
| 11:05.33 | freemangordon | jon_y: /usr/bin/osso-addressbook |
| 11:05.59 | jon_y | a reimplementation would take years, probably |
| 11:06.17 | freemangordon | well, that could be done in a clever way |
| 11:06.25 | freemangordon | but still not easy |
| 11:06.52 | freemangordon | i.e. a second backend keeping only one osso-abook instance for the system |
| 11:06.58 | ShadowJK | If I'd make a cynical guess, sqlite was involved in backend and it became too slow so they load entire abook into everything? :) |
| 11:07.15 | freemangordon | ShadowJK: afaik it is berkeley db |
| 11:07.28 | jon_y | lets put mysql in there instead :) |
| 11:07.58 | jon_y | or OracleDB if we have $$$$ |
| 11:08.08 | ShadowJK | stabs jon_y with a tusty fork |
| 11:08.18 | freemangordon | ShadowJK: but you have a point here, it might be that abook loads libdb4.2, which caches everything in memory |
| 11:08.24 | jon_y | feel the enterprise-ness |
| 11:08.41 | freemangordon | aah, why people don;t trust OS to cache the fs :( |
| 11:08.52 | jon_y | freemangordon: does fork() call get involved in there? |
| 11:08.59 | freemangordon | jon_y: no |
| 11:09.06 | ShadowJK | jon_y; if we had 16 xeon cores and 128 gig ram and a raid-0 of Intel S3700 SSDs |
| 11:09.15 | freemangordon | I rebuilt hildon-status-menu withou .launcer stuff |
| 11:09.29 | jon_y | ok, I was suspecting fork is duplicating the DB heap if something wrote to it |
| 11:09.31 | freemangordon | it still uses ~ 5MB |
| 11:09.40 | ShadowJK | but these things usually slow even harddrives down to a crawl, and is about 1000 times worse on flash |
| 11:09.43 | freemangordon | jon_y: no, as exec follows fork |
| 11:09.52 | jon_y | ok |
| 11:10.25 | freemangordon | but removing librtcom... plugins reduces heap usage by $ MB |
| 11:10.28 | freemangordon | *4MB |
| 11:11.35 | freemangordon | yeah, libosso-abook-1.0.so.0 imports libdb-4.2.so |
| 11:11.48 | freemangordon | hmm, lemme check something |
| 11:15.25 | *** join/#maemo-ssu kolp (~quassel@212.255.20.168) |
| 11:20.21 | freemangordon | well, seems like it is berkeley DB caching the data |
| 11:21.29 | jon_y | how many instances are there? |
| 11:21.43 | freemangordon | there is no instance |
| 11:21.50 | freemangordon | it is .so |
| 11:22.05 | kerio | ShadowJK: srsly though, would mtdswap make it better? |
| 11:22.23 | jon_y | freemangordon: I mean of the BDB cache |
| 11:22.41 | freemangordon | seems like every application using it has its own cache |
| 11:22.48 | jon_y | I would assume loading the .so means a heap for every client |
| 11:23.04 | freemangordon | looks like |
| 11:23.04 | jon_y | that would explain things |
| 11:23.21 | freemangordon | I wonder why it is not using mmap |
| 11:23.30 | jon_y | windows developers? |
| 11:23.33 | jon_y | interns? |
| 11:23.40 | freemangordon | oracle ;) |
| 11:23.45 | jon_y | :) |
| 11:24.09 | jon_y | I had to read through C code written by an CS intern once, it wasn't pretty |
| 11:24.15 | ShadowJK | kerio; make what better |
| 11:24.48 | jon_y | you need GLIB to prevent memleaks?? you suck bad |
| 11:25.09 | jon_y | you need that too to read directory entries and cat strings?? |
| 11:25.22 | kerio | ShadowJK: the N900 as a whole |
| 11:25.39 | jon_y | surfice to say the code is now part of a critical infrastructure :( |
| 11:26.02 | jon_y | it's a blackbox that no one wants to touch |
| 11:26.25 | ShadowJK | kerio; i think the optimal algorithm for sd/mmc is same as for onenand, so if they've got good gc implemented in it I'd put that in normal swap algo |
| 11:27.10 | kerio | idk, mtdswap is apparently an actual thing |
| 11:27.14 | kerio | it's in mainline |
| 11:29.44 | ShadowJK | wonders if N950/N9 has emmc that does more than 1-2 IOPS :) |
| 11:29.45 | freemangordon | hmm, seems heap can be disabled during build time. and maximum can be set at runtime |
| 11:30.50 | jon_y | freemangordon: it still won't stop copies of caches per client |
| 11:31.14 | freemangordon | yes, but if we free 10MB, i'll be happy |
| 11:31.26 | jon_y | imho libdb-4.2.so should not be used directly by DB clients |
| 11:31.36 | freemangordon | why? |
| 11:31.37 | jon_y | except to talk to a singleton server instance |
| 11:31.47 | freemangordon | there is no server |
| 11:31.49 | jon_y | that would be the ideal case anyway |
| 11:31.53 | freemangordon | ofc |
| 11:32.01 | freemangordon | but there is no server |
| 11:32.22 | jon_y | yeah I know, which is kind of an architectural problem |
| 11:34.06 | kerio | ShadowJK: wouldn't mtdswap wear out the flash pretty quickly, on the n900? |
| 11:34.28 | ShadowJK | shrugs |
| 11:34.41 | ShadowJK | using that tiny thing doesn't interest me much |
| 11:35.26 | ShadowJK | I'm waiting for my new microsd to arrive. It claims 100-150 iops random write. |
| 11:36.02 | ShadowJK | If true performance is a tenth of that, it's still factor 5-10 improvement over every other microsd :) |
| 11:39.32 | kerio | ShadowJK: are IOPS actually that important, compared to, say, random write speed? |
| 11:43.50 | kerio | ShadowJK: also, the onenand will still be much faster in every regard |
| 11:48.59 | ShadowJK | iops IS random write speed |
| 11:50.53 | kerio | hm, right |
| 11:51.25 | kerio | hm, how would you measure the IOPS of a uSD? |
| 11:51.36 | kerio | how many writes of... how much? |
| 11:51.41 | kerio | in one second |
| 12:20.14 | ShadowJK | 4k random write |
| 12:21.12 | kerio | ShadowJK: ...150 of those in one second? :O |
| 12:21.21 | kerio | where is this marvel of technology |
| 12:21.29 | kerio | i wanna buy it |
| 12:24.18 | jon_y | fast, cheap, reliable, choose 1 :) |
| 12:25.08 | kerio | i know |
| 12:33.49 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 13:44.43 | DocScrutinizer05 | freemangordon: (hildon-status-menu 'heap usage') wait wait.... It's started via *.launch? |
| 13:50.05 | DocScrutinizer05 | freemangordon: you say you know what launcher does, but I'm not convinced you do. launcher shares a memory region to all .launch'ed processes, so the per-process mem usage is largely bogus |
| 13:51.30 | DocScrutinizer05 | so even a tiny process started as process.launch will show to have enormous amount of memory, but all of that memory is shared with all other .launched processes and thus the actual increase in RAM usage of whole system is *smaller* this way |
| 13:52.39 | *** join/#maemo-ssu don_falcone (~Miranda@88.128.58.112) |
| 13:53.30 | *** join/#maemo-ssu toxarisswe (~toxaris@s83-180-246-172.cust.tele2.se) |
| 13:55.48 | don_falcone | hi, any1 seen luf lately? |
| 13:59.44 | DocScrutinizer05 | ~seen luf |
| 13:59.48 | infobot | luf <luf@nat/ibm/x-eeonivbxbcxtjtwl> was last seen on IRC in channel #maemo-ssu, 3d 15m 21s ago, saying: 'DocScrutinizer05: do you mean some alu plactic?'. |
| 14:02.33 | DocScrutinizer05 | (.launch) it's basically same concept used for mce-plugins and (aiui) system-ui plugins |
| 14:06.33 | don_falcone | damn i hated those scripts already back in the days... *scratches head* |
| 14:20.39 | kerio | ShadowJK: no srsly gimme a link for your magical uSD |
| 14:25.11 | ShadowJK | http://www.adata-group.com/index.php?action=product_feature&cid=7&piid=178 |
| 14:25.56 | ShadowJK | http://www.adata-group.com/upload/ProductFeature/productImage3281.jpg :o |
| 14:26.36 | freemangordon | DocScrutinizer05: for sure launcher does exec() |
| 14:26.51 | freemangordon | and that frees all malloc()-ed memory |
| 14:27.27 | freemangordon | also there is no way (afaik) heap to be shared |
| 14:28.27 | freemangordon | DocScrutinizer05: but at the end it seems all that memory is used by addressbook |
| 14:29.36 | freemangordon | DocScrutinizer05: for example removing librtcom-... plugins from status menu (both use libosso-abook) reduces heap usage by 3-4 MB |
| 14:29.55 | kerio | ShadowJK: hrmpf, i can't find an actual online seller |
| 14:31.22 | ShadowJK | You could have a launcher that loads common data into a format and data structures used by common apps, and you could fork and exec in a way that leaves that data around, and it'd be copy-on-write and shared between all the apps as long as they don't modify it |
| 14:31.34 | DocScrutinizer05 | freemangordon: maybe I missed sth in prev convo, but I know ${randomprocess}.launch is basically a .so that gets loaded to main process |
| 14:31.47 | DocScrutinizer05 | *one* main process |
| 14:32.09 | DocScrutinizer05 | at least that's been the idea and description of what maemo-invoker does |
| 14:33.49 | freemangordon | ShadowJK: as long as you do exec(), heap gets destroyed/freed |
| 14:34.04 | kerio | ShadowJK: holy shit, a 32GB of those for 65 USD on amazon us |
| 14:34.21 | freemangordon | DocScrutinizer05: i've compiled hildon-status-menu with nolauncher option, memory usage remains the same |
| 14:34.45 | DocScrutinizer05 | wee |
| 14:34.52 | DocScrutinizer05 | well, obviously |
| 14:34.53 | kerio | hahahahaha 92€ for the same one on amazon it |
| 14:35.24 | freemangordon | ShadowJK: read long as soon :) |
| 14:35.35 | DocScrutinizer05 | since it's just the one difference that with nolauncher, the memory isn't shared from maemo-invoker, but actually alloc'ed |
| 14:35.42 | kerio | ShadowJK: hm, the description on amazon UK states "random write (IOPS) speeds are as high as 50" |
| 14:35.54 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 14:36.13 | freemangordon | DocScrutinizer05: in both cases memory is malloc()-ed |
| 14:36.34 | freemangordon | the difference is that with .launcher you share GTK stuff |
| 14:36.47 | freemangordon | (ifusing GTK booster) |
| 14:37.04 | DocScrutinizer05 | freemangordon: though... it should *not* allocate memory for stuff it doesn't use at all and that would get shared by maemo-invoker just because some other process pulled it in to shared memory pool |
| 14:37.18 | freemangordon | it does not |
| 14:37.49 | freemangordon | aiui maemo-launcher exploits copy-on-write |
| 14:38.37 | freemangordon | i.e. gtk relocations? is shared amongst all of the processes |
| 14:38.44 | freemangordon | or something like that |
| 14:38.54 | freemangordon | but heap is not shared, that is for sure |
| 14:39.38 | freemangordon | anywa, high heap usage is not because of the .launcher, no matter what it does |
| 14:40.20 | freemangordon | DocScrutinizer05: for example contact widget process uses 2100KB of heap |
| 14:40.46 | freemangordon | and I can bet it is because it uses osso-abook |
| 14:41.34 | freemangordon | still cannot understand who caches the whole db in memory - is it berkeley db, or EDS or NFC who |
| 14:42.18 | jon_y | can't valgrind? |
| 14:42.33 | freemangordon | won;t help |
| 14:42.38 | freemangordon | aiui |
| 14:43.05 | freemangordon | this is not a memory leak, but inefficien memory usage |
| 14:43.07 | jon_y | how about you inject/preload your .so to intercept malloc/free calls |
| 14:43.16 | freemangordon | ^^^ |
| 14:43.31 | jon_y | iirc valgrind can also intercept such calls |
| 14:43.43 | freemangordon | as ShadowJK pointed, that seems like a broken design |
| 14:44.10 | jon_y | you could at least in theory tell were the heap alloc was called from |
| 14:44.12 | freemangordon | jon_y: sure, but how that will help, elaborate please. |
| 14:44.21 | kerio | easy fix: don't make phone calls |
| 14:44.26 | freemangordon | without debug symbols? |
| 14:44.33 | freemangordon | i doubt |
| 14:45.00 | freemangordon | there is a whole chain if closed source binaries |
| 14:45.00 | jon_y | .so mapping to tell where they come from? |
| 14:45.11 | jon_y | s/.so/.text/ |
| 14:45.32 | freemangordon | don't know what you mean |
| 14:45.50 | freemangordon | aaah |
| 14:45.56 | freemangordon | got it |
| 14:45.58 | jon_y | each executable is loaded at a VM address, those malloc calls have to come from somewhere |
| 14:46.05 | freemangordon | yeah, yeah |
| 14:47.03 | jon_y | you should be able to tell if the heap is owned by the GTk libs or BDB or whatever |
| 14:48.00 | freemangordon | what I cannot undersand is - BDB uses mmap, why it needs to cache in heap too? |
| 14:48.40 | jon_y | no idea, you found out the heap is owned by BDB? |
| 14:48.54 | freemangordon | no. but i suspect that |
| 14:49.03 | jon_y | their logic probably heap is faster than disk |
| 14:49.16 | jon_y | though it runs afoul when you have very limited RAM |
| 14:49.41 | freemangordon | heap is almost the same as the size as log.0000001 file |
| 14:49.54 | freemangordon | in ~/.osso-abook/db |
| 14:51.09 | jon_y | sadly, you'll need to step into the BDB code to confirm the behavior |
| 14:51.24 | freemangordon | it is open source, so NP |
| 14:51.47 | jon_y | yeah, a debug version might come handy |
| 14:52.31 | jon_y | you should also match the malloc calls to the free calls, to screen out temporary heap allocs |
| 14:52.43 | freemangordon | DocScrutinizer05: would you check what is the memory usage on your stock device of /usr/bin/osso-abook-home-applet |
| 14:53.05 | jon_y | off to sleep now |
| 14:53.11 | jon_y | good luck in your debug runs |
| 14:54.36 | DocScrutinizer05 | hard to do on stock device. I can do on CSSU-T device |
| 14:56.23 | freemangordon | :( |
| 14:56.42 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 14:56.51 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 14:56.55 | freemangordon | i'll ask on #maemo |
| 14:59.03 | DocScrutinizer05 | how would cssu-t differ from stock in that regard? |
| 14:59.50 | DocScrutinizer05 | or, if you prefer, I can do that on a "stock hildon" with KP46(?) system |
| 15:00.11 | kerio | DocScrutinizer05: why? |
| 15:00.15 | kerio | stock has no /proc? |
| 15:00.16 | kerio | :o |
| 15:00.21 | DocScrutinizer05 | - - - 14608 1528 1400 40 288 0 0 1 1980 user 20 1 S - - - 0:01.58 0.0 0.6 /usr/bin/mafw-playlist-daemon |
| 15:00.24 | DocScrutinizer05 | - - - VIRT RES SHR CODE DATA LIB DIRTY PPID PID USER PRI NI S - - - TIME+ CPU% MEM% Command |
| 15:01.19 | DocScrutinizer05 | kerio: what? |
| 15:01.32 | freemangordon | DocScrutinizer05: "stock" as "no CSSU" |
| 15:01.44 | freemangordon | just in case |
| 15:01.45 | kerio | why can't you check the memory occupation on a stock device? |
| 15:02.19 | freemangordon | DocScrutinizer05: and i need heap section in /proc/.../smaps |
| 15:02.20 | DocScrutinizer05 | kerio: please reread, I never said anything like that |
| 15:03.00 | freemangordon | alnog with the size of /home/user/.osso-abook/db/log.0000000001 |
| 15:03.02 | DocScrutinizer05 | I said I got no stock device. That's all |
| 15:03.04 | freemangordon | *along |
| 15:03.07 | kerio | oic |
| 15:04.32 | DocScrutinizer05 | freemangordon: maybe pasting the cmdline here would yield most exactly matching results to what you wanna see? |
| 15:05.42 | freemangordon | grep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps |
| 15:05.50 | DocScrutinizer05 | since nobody (incl me, but for sure 'mere mortals' in #maemo) CBA to figure what your request translates to, in terms of cmdline incantation |
| 15:06.03 | freemangordon | DocScrutinizer05: ^^^ |
| 15:08.56 | DocScrutinizer05 | 00016000-00298000 rw-p 00016000 00:00 0 [heap] Size: 2568 kB Rss: 524 kB Pss: 520 kB Shared_Clean: 4 kB Shared_Dirty: 0 kB Private_Clean: 148 kB Private_Dirty: 372 kB Referenced: 360 kB Swap: 2012 kB |
| 15:10.40 | DocScrutinizer05 | grep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps|tr -d '\n' |
| 15:13.06 | freemangordon | yeah, 2568 kB |
| 15:19.04 | DocScrutinizer05 | grep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps|tr '\n' '!' |
| 15:19.31 | DocScrutinizer05 | 00016000-00298000 rw-p 00016000 00:00 0 [heap]!Size: 2568 kB!Rss: 516 kB!Pss: 512 kB!Shared_Clean: 4 kB!Shared_Dirty: 0 kB!Private_Clean: 148 kB!Private_Dirty: 364 kB!Referenced: 296 kB!Swap: 2020 kB! |
| 15:20.12 | DocScrutinizer05 | 2568 is not heap size |
| 15:20.12 | freemangordon | 00016000-00223000 rw-p 00016000 00:00 0 [heap]!Size: 2100 kB!Rss: 1824 kB!Pss: 1808 kB!Shared_Clean: 16 kB!Shared_Dirty: 4 kB!Private_Clean: 336 kB!Private_Dirty: 1468 kB!Referenced: 1616 kB!Swap: 272 kB! |
| 15:20.26 | freemangordon | DocScrutinizer05: but? |
| 15:20.46 | DocScrutinizer05 | just "Size" |
| 15:20.58 | freemangordon | what?!? |
| 15:21.18 | freemangordon | the size: in [hep] section souns like heap size to me :P |
| 15:21.23 | freemangordon | *[heap] |
| 15:21.52 | DocScrutinizer05 | 00016000-00298000 rw-p 00016000 00:00 0 [heap] |
| 15:21.57 | DocScrutinizer05 | heap section |
| 15:22.12 | DocScrutinizer05 | Size: 2568 kB |
| 15:22.16 | DocScrutinizer05 | size section? |
| 15:23.50 | freemangordon | DocScrutinizer05: you are trying to say this is not the total of malloc()-ed memory? |
| 15:24.28 | DocScrutinizer05 | I'm not trying to say anything, probably |
| 15:24.30 | DocScrutinizer05 | nm |
| 15:24.35 | freemangordon | ok :) |
| 15:26.51 | freemangordon | well, we can easily test that: int main(){ void * p = malloc(2048*1024); while(1) usleep(10000000);} |
| 15:27.30 | DocScrutinizer05 | sorry, short on milk, thus no coffe yet here |
| 15:30.16 | DocScrutinizer05 | I can easily figure how some #include will pull in a shitload of buffers and stuff to every process using it |
| 15:30.45 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2822F.dip0.t-ipconnect.de) |
| 15:31.09 | DocScrutinizer05 | instantiate a object my-Abook |
| 15:31.17 | DocScrutinizer05 | damage done |
| 15:31.35 | DocScrutinizer05 | watch insane roaster shit |
| 15:31.53 | DocScrutinizer05 | docs about abook are disgusting |
| 15:33.17 | Lava_Croft | http://img.gawkerassets.com/img/185owo0236jdvjpg/original.jpg |
| 15:33.54 | DocScrutinizer05 | http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookAggregator.html#osso-abook-aggregator-find-contacts-for-phone-number etc |
| 15:34.42 | DocScrutinizer05 | see http://talk.maemo.org/showthread.php?t=60526&page=3 |
| 15:35.24 | freemangordon | will do |
| 15:35.48 | DocScrutinizer05 | actually http://talk.maemo.org/showpost.php?p=990571&postcount=15 |
| 15:38.48 | DocScrutinizer05 | Lava_Croft: epic fail |
| 15:39.50 | Lava_Croft | not exactly epic, but very much fail |
| 15:41.22 | DocScrutinizer05 | http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Generic_Platform_Components/Using_Address_Book_API |
| 15:41.38 | DocScrutinizer05 | ( freemangordon ^^^) |
| 15:45.17 | DocScrutinizer05 | for sure you don't want to use any of that bloated cruft to just get your own avatar picture |
| 15:45.31 | DocScrutinizer05 | or sth silly as that |
| 16:23.26 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 16:36.46 | freemangordon | DocScrutinizer05: why should I read the API docs? |
| 16:40.45 | DocScrutinizer05 | not complete API docs, I just linked to it for giving an idea how much cruft there might come with touching any bit of libabook |
| 16:42.02 | DocScrutinizer05 | freemangordon: actually I'd not recommend to anybody to read these API docs, since as I mentioned I think they're not exactly bearable |
| 16:42.37 | freemangordon | yeah |
| 16:42.56 | kerio | Lava_Croft: haha |
| 16:43.24 | kerio | by the way, should i install nitdroid? |
| 16:50.41 | DocScrutinizer05 | hands kerio a gun to shoot his own foot, for the better alternative to installing nitdroid |
| 16:51.42 | kerio | DocScrutinizer05: why? what's so bad about it? |
| 16:54.36 | Lava_Croft | there's not really a reason to install android on a device which has an OS like Maemo |
| 16:54.41 | Lava_Croft | unless you like game X orso |
| 16:55.02 | kerio | but... dual booting! |
| 16:56.30 | kerio | it's fun! |
| 16:56.31 | DocScrutinizer05 | ~maemo-multiboot |
| 16:56.31 | infobot | maemo-multiboot is probably deprecated, and a horrible hack. PROBLEMS WITH NITDROID/MULTIBOOT? reflash rootfs&kernel aka COMBINED |
| 16:56.42 | kerio | >implying i'd use multiboot |
| 16:56.54 | DocScrutinizer05 | kerio: your trolling today is extremely weak |
| 16:57.08 | kerio | seriously though, i feel somewhat insulted :< |
| 16:58.46 | DocScrutinizer05 | my general notion that never changed: if you want andridiot, get a device that ships with this abomination. Those are cheap and modern and way more powerful than N900 |
| 16:59.30 | DocScrutinizer05 | nobody would want to run android on N900, why would you? |
| 17:27.21 | kerio | i wonder how to grab a partition out of an image of a block device that has a partition table |
| 17:30.34 | kerio | also, why does the nemo image have an 8mb swap partition? |
| 17:33.55 | Lava_Croft | I like grown up people turning names of operating systems into 'hidden' insults |
| 17:34.41 | DocScrutinizer05 | kerio: that's an illegal configuration. Partition table has to be in MBR aka block0 |
| 17:34.53 | DocScrutinizer05 | of the physical device |
| 17:35.35 | kerio | DocScrutinizer05: i know, but doing dd if=/dev/sdb of=rawimg is convenient |
| 17:35.38 | kerio | and common |
| 17:39.37 | DocScrutinizer05 | I love users delivering their critics/concerns wrapped into a loosely related statement about their moods, containing another wrapper of sarcasm, containing a 3rd wrapper of hard to even detect irony |
| 17:40.11 | Lava_Croft | I was being pretty serious |
| 17:40.28 | *** join/#maemo-ssu FIQ|n900 (~FIQ@unaffiliated/fiq) |
| 17:40.40 | DocScrutinizer05 | so I'm pleased you enjoy my special humour |
| 17:40.53 | Lava_Croft | short bus special, |
| 17:42.32 | kerio | grabs some popcorn |
| 17:43.06 | *** join/#maemo-ssu iDont (~iDont@dhcp-077-250-143-002.chello.nl) |
| 17:43.18 | DocScrutinizer05 | kerio: sorry, i won't continue this futile "coversation" |
| 17:45.05 | DocScrutinizer05 | kerio: If you wanna take over, utter something negative and use the letters "M$" |
| 17:45.40 | DocScrutinizer05 | or the term windoze |
| 17:45.55 | ShadowJK | kerio; heh, I usually fdisk -lu when I image drives, so I can pick out partitions with offsets and loop device later if needed |
| 17:46.00 | Lava_Croft | m$ is a term that is not insulting at all |
| 17:46.08 | Lava_Croft | since MS is a company and companies are all about $$$$ |
| 17:46.20 | Lava_Croft | Windoze does not contain an insult either, its just bad spelling/bad slag |
| 17:46.25 | Lava_Croft | slang* |
| 17:49.23 | DocScrutinizer05 | kerio: sorry, then. You see you have to come up with something better to make Lava_Croft like you better than me |
| 17:50.21 | Lava_Croft | Q_Q some more |
| 17:50.22 | kerio | Windows Visyou fucking cuntta |
| 17:50.37 | Lava_Croft | And people wonder why niches stay niches |
| 18:44.28 | *** join/#maemo-ssu FIQ|n900 (~FIQ@unaffiliated/fiq) |
| 19:02.54 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2822F.dip0.t-ipconnect.de) |
| 19:06.11 | *** join/#maemo-ssu FIQ (~fiq@unaffiliated/fiq) |
| 19:16.09 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2822F.dip0.t-ipconnect.de) |
| 19:50.50 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 20:00.51 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 20:20.49 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 20:24.10 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 20:30.18 | freemangordon | ~seen luf |
| 20:30.26 | infobot | luf <luf@nat/ibm/x-eeonivbxbcxtjtwl> was last seen on IRC in channel #maemo-ssu, 3d 6h 45m 59s ago, saying: 'DocScrutinizer05: do you mean some alu plactic?'. |
| 20:30.43 | freemangordon | :( |
| 20:38.10 | kerio | :( |
| 20:48.17 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 21:37.25 | *** join/#maemo-ssu trumee (~parul@93-96-159-40.zone4.bethere.co.uk) |
| 21:52.24 | *** join/#maemo-ssu Jade (~jade@modemcable190.180-203-24.mc.videotron.ca) |
| 21:52.24 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
| 22:01.03 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:17.39 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 22:27.11 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 22:30.27 | *** join/#maemo-ssu peetah (~peetah@cha92-9-82-236-202-86.fbx.proxad.net) |
| 22:40.39 | *** join/#maemo-ssu Jade (~jade@Jade.broker.freenet6.net) |
| 22:40.39 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
| 23:01.20 | *** join/#maemo-ssu arcean (~arcean@aaes158.neoplus.adsl.tpnet.pl) |
| 23:09.02 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
