**** BEGIN LOGGING AT Tue Nov 26 02:59:58 2013 Nov 26 08:24:46 freemangordon: I would not worry about misterc. He is a well known idiot. Nov 26 10:54:31 I guess its not #wine Nov 26 10:56:07 what? Nov 26 11:00:08 vi__: I seek help in running a windows program in linux under the emulator named wine Nov 26 11:00:18 which channel should I ask in? Nov 26 11:01:51 wine==wine is not an emulator! Nov 26 11:02:00 I do not know Nov 26 11:02:25 #winehq Nov 26 11:02:41 a simple google search would have answered your question in ~ 3seconds. Nov 26 11:04:24 sorry vi Nov 26 11:04:35 do you use wine and can help me? Nov 26 11:05:26 how can I tell the session is using the "native" rasapi32 ? Nov 26 11:05:35 I mean I changed it in the winecfg Nov 26 11:05:59 I have no idea. I have no used wine since I tried to play half life 2. Nov 26 11:06:06 try #winehq Nov 26 11:06:55 thnaks Nov 26 12:02:04 just turned on my N900 after two and a half years Nov 26 12:02:21 after ~ 1 hour battery charge, of course Nov 26 12:02:50 and everything seems to be still working Nov 26 12:02:51 :) Nov 26 12:06:22 built for eternity (except usb slot) Nov 26 12:07:20 :) Nov 26 12:07:40 http://tvtropes.org/pmwiki/pmwiki.php/Main/RagnarokProofing Nov 26 12:10:22 yeah, just remembered that. I had to leave my N900 in a weird position, just to charge it. :( Nov 26 12:11:43 updating packages right now. Long time I don't follow updates for n900. I still have a modified linux kernel -- not sure if it's being supported yet. Nov 26 16:39:28 vi__: well, I tend to always try to help people, idiots included :) Nov 26 16:57:54 freemangordon: I did not choose the thumb2 life, the thumb2 life chose me. Nov 26 18:30:13 DocScrutinizer05: they're trying to get you! run! run for the hills! Nov 26 19:09:05 run for your liveesssss Nov 26 19:10:09 http://www.youtube.com/watch?v=geHLdg_VNww Nov 26 19:16:56 so predictable! Nov 26 19:24:00 hehe Nov 26 19:46:04 hello there! After a few strace sessions to investigate about the modest performace, i think i have found a trick that could increase the maemo performace systewide... SO ... i would ask for testers and ideas to understand this behavior (if it's the same also for you). The trick is: ln -s /usr/share/icons /home/user/.icons Strange? Stupid? maybe... but try it Nov 26 19:47:04 u wot Nov 26 20:06:32 o.O Nov 26 20:06:38 kerio: what is strange is that modest interaction really seems faster Nov 26 20:06:56 >implying anyone uses modest Nov 26 20:07:03 wut? Nov 26 20:07:07 I use it Nov 26 20:07:18 aah, only modest (the modest modest mail app)? Nov 26 20:07:55 guys, wait, the point is that it could have a system-wide speedup. If true Nov 26 20:08:02 >>that could increase the maemo performace systewide<< Nov 26 20:08:46 because I doubt modest is using /usr/share/icons without help from some lib. gtk? Nov 26 20:09:03 but we need a confirmation/not Nov 26 20:09:07 and a testcase Nov 26 20:09:54 well, I know xes and his experience and very understatement way to post things. But that... needs a *tad* more rationale before I invest any time into it. Since without proper understand on how it's meant to work, I can't check if it actually does Nov 26 20:16:03 also I wonder if a ln -s /opt/usr/share/icons /home/user/.icons wasn't even more effective, if that whole thing is any effective at all Nov 26 20:16:35 :nod: Nov 26 20:16:44 i doubt it's the actual path resolution Nov 26 20:16:51 and then, why not already ln /opt/usr/share/icons /home/user/.icons Nov 26 20:16:53 linux's VFS is good enough Nov 26 20:17:08 kerio: but what could be then? Nov 26 20:17:09 DocScrutinizer05: because you can't hardlink directories :s Nov 26 20:17:20 oh, I can't? Nov 26 20:17:38 not even root can Nov 26 20:17:44 do you think you're better than root? Nov 26 20:18:00 do you think you can beat me at trolling ;-P Nov 26 20:18:34 mount --bind /opt/usr/share/icons /home/user/.icons Nov 26 20:18:46 kerio: DocScrutinizer05: the reason could be that someone tries access() or open() or whatever for /home/user/.icons first Nov 26 20:18:56 indeed! Nov 26 20:19:07 but why does that cause a performance hit? Nov 26 20:19:47 hmm, gtk rc? Nov 26 20:19:58 freemangordon: thought as much Nov 26 20:20:11 also I fail to see the mega performance impact Nov 26 20:20:12 trying to preload the whole theme? Nov 26 20:21:10 a stat() is utterly fast, particularly when done often in sequence (and otherwise it wouldn't matter anyway) since then all relevant disk blocks are in biffers already Nov 26 20:21:22 indeed Nov 26 20:21:22 xes: according to your strace, what modests looks for in /home/user/.icons? Nov 26 20:21:49 buffers even Nov 26 20:21:56 :nod: Nov 26 20:22:01 freemangordon: all the icons of the gtk theme Nov 26 20:22:20 ...ok, that could cause a performance hit Nov 26 20:23:11 how so? Nov 26 20:23:22 it's still only a few hundred stat() Nov 26 20:23:32 to a non-existing dir Nov 26 20:23:42 always same dir Nov 26 20:23:47 modest searches for icons also in /usr/local/share/icons Nov 26 20:23:53 ( /home/user/.icons ) Nov 26 20:24:05 xes: what finction it executes? Nov 26 20:24:10 *function Nov 26 20:24:18 DocScrutinizer05: open() Nov 26 20:24:36 doesn't change much Nov 26 20:24:50 hmm there are hundreds of icons Nov 26 20:24:57 I think a failing open() is as fast as a failing stat() Nov 26 20:25:25 yep, but calling that hundreds of times takes time Nov 26 20:25:27 you are free to try: strace -e open -p _modest_pid_ Nov 26 20:25:33 did you use profiling/timestamping in strace? Nov 26 20:26:06 xes: does that happen only when starting modest? Nov 26 20:26:18 DocScrutinizer05: no Nov 26 20:26:54 freemangordon: i have straced only modest but i'm almost sure the behavior is valid also for other apps Nov 26 20:26:56 I bet N900 can execute 1000s of failing open() to same pathname per second Nov 26 20:27:50 i have also add a few other symlinks.... i have to check, i can't remember, it seems that it' s searching for many things in the wrong places Nov 26 20:28:14 freemangordon: for (i=0; i<1000000; i++); open("/home/user/foobar"); Nov 26 20:28:31 time a.out Nov 26 20:29:04 DocScrutinizer05: sure. This is what i was expecting.... but this is now what i think i have obtained Nov 26 20:29:28 xes: it definitely does, since you can override virtually every file by a similar file in your home dir Nov 26 20:29:56 DocScrutinizer51: going to try it Nov 26 20:31:40 freemangordon: stop! Nov 26 20:31:46 DocScrutinizer05: thoug, it is not exactly correct, it should be foobar%d IMO Nov 26 20:31:52 freemangordon: for (i=0; i<1000000; i++); open("/home/user/$i"); Nov 26 20:31:59 sorry for wrong syntax Nov 26 20:32:01 sorry.... *this is not what i think i have obtained Nov 26 20:32:18 xes: hmm? Nov 26 20:33:21 i mean ...i wasn't expecting a speedup. But this is what i'm experiencing Nov 26 20:33:35 aah Nov 26 20:33:54 xes: do you remember open() flags? Nov 26 20:34:25 O_RDONLY? Nov 26 20:34:35 so you see a speedup where you only expected a theoretical improvement that you wouldn't expect to have any noticeable effect? Nov 26 20:34:43 freemangordon: yep Nov 26 20:35:20 freemangordon: sorry i should test it again, it's been a few days since first test Nov 26 20:35:24 well, who knows Nov 26 20:35:38 DocScrutinizer05: yep Nov 26 20:35:41 xes: we already are about to test it ;-D Nov 26 20:36:11 though strace with timestamps/profiling would be highly appreciated too, of course Nov 26 20:37:24 was that strace that even prints statistics of average/min/max duration for each function called? Nov 26 20:37:31 iterating 1000000 times takes ages Nov 26 20:37:46 Nokia-N900:~# time ./opentest Nov 26 20:37:47 real 0m 33.67s Nov 26 20:37:47 user 0m 5.02s Nov 26 20:37:47 hehe Nov 26 20:37:47 sys 0m 26.62s Nov 26 20:37:54 ages? Nov 26 20:38:06 will try 10000 times Nov 26 20:38:32 that's 26us per open() Nov 26 20:38:37 yep Nov 26 20:38:47 about what I expected Nov 26 20:38:50 combine that with /usr/share/local Nov 26 20:39:08 so 50us per open Nov 26 20:39:20 you mean the symlink dereference? Nov 26 20:39:56 I mean that it searches /home/user first, then /usr/share/local and then /usr/share Nov 26 20:40:05 aah Nov 26 20:40:16 :nod: Nov 26 20:40:41 keep in mind my device is OC to 805 Nov 26 20:40:44 though, correctly:twice the number of open() calls Nov 26 20:41:03 :nod: Nov 26 20:41:28 but then, how many icons can a arbitrary app open()? Nov 26 20:41:31 1000? Nov 26 20:41:35 5000? Nov 26 20:41:52 DocScrutinizer05: not sure how many of them are in the gtk theme Nov 26 20:42:00 but there are lots of them Nov 26 20:42:03 I'd say thousands Nov 26 20:42:15 an app will not open all existing icons, only the ones it needs Nov 26 20:42:38 iirc gtk builds a list Nov 26 20:42:48 :EEEEK: Nov 26 20:42:57 not sure about that one though Nov 26 20:43:10 list processing is DA SHITE, the killer for every program Nov 26 20:43:30 HAM is slow mainly for list processing I guess Nov 26 20:43:50 but iirc everytime you create a new GtkStyle (or whatever it was called) you got a copy of the default style Nov 26 20:44:17 use strace, and time Nov 26 20:44:22 will tell Nov 26 20:44:31 xes: when those open()calls happe? only on modest startup or all over the place Nov 26 20:45:04 DocScrutinizer05: HAM is slow, because libapt (c++ library) is slow in iterating all of packages Nov 26 20:45:28 ps aux | grep modest and strace -e open -p the second one. Then open modest app Nov 26 20:45:38 I already found hot code (for loop), but there is no way how to speed up it Nov 26 20:45:57 xes: op Nov 26 20:45:59 *ok Nov 26 20:49:06 freemangordon: then start opening mails from your inbox... Nov 26 20:50:01 sorry, can't do since no modest configured here Nov 26 20:50:20 xes: about 5 open() call per mail Nov 26 20:50:26 not much of a win Nov 26 20:50:29 kerio: you might be right (re dir hardlinks) Nov 26 20:51:02 -d, -F, --directory Nov 26 20:51:03 allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser) Nov 26 20:51:13 freemangordon: yep. Not enough to explain the difference Nov 26 20:51:13 xes: this has no visible effect Nov 26 20:51:20 pretty verbose explanation Nov 26 20:51:34 i'm not "probably" right Nov 26 20:51:35 i'm right Nov 26 20:52:12 no, you're *probably* right, since >>note: will *probably* fail << Nov 26 20:52:29 I guess it depends on filesystem Nov 26 20:52:38 and on build options Nov 26 20:52:44 xes: it'd be good if you can do some real measurement, like DocScrutinizer05 proposed ^^^, with strace timing Nov 26 20:53:34 -c Count time, calls, and errors for each system call and report a summary on program exit. On Linux, this attempts to show system time (CPU time spent running Nov 26 20:53:35 in the kernel) independent of wall clock time. If -c is used with -f or -F (below), only aggregate totals for all traced processes are kept. Nov 26 20:53:44 DocScrutinizer05: ext* FS does not allow you to create hard link on directories Nov 26 20:53:52 ext* kernel drivers reject it Nov 26 20:54:06 and I think that in recent kernel versions also VFS reject it Nov 26 20:54:15 Pali: that's what I suspected Nov 26 20:54:50 but I read that somebody successfully edited ext4 kernel driver (removed restriction) and it worked :-) Nov 26 20:55:00 funny enough on NTFS it works Nov 26 20:55:02 Pali: seems like you and fbalbi will become friends at the end :D Nov 26 20:55:04 but there was problem with find utility Nov 26 20:55:08 though only with a special tool Nov 26 20:55:38 but after next fsck.ext4 call, it removed that duplicate directory hard-link Nov 26 20:55:49 the filesystem tree should be a directed acyclic graph Nov 26 20:56:01 if you allow directory hardlinks, you add the possibility for cycles Nov 26 20:56:14 and that would confuse the hell out of everyone Nov 26 20:56:15 kerio: right, DAG is very good for FS :-) Nov 26 20:56:32 bindmounts don't have bindmounts in them Nov 26 20:56:37 that's why they're allowed Nov 26 20:56:44 Pali: LOL Nov 26 20:56:52 @ fsck Nov 26 20:57:15 DocScrutinizer05: so if you create somehow direcory hardlink (hexedit /dev/sda), then every FS code/part will remove it :D Nov 26 20:57:26 kernel driver, fsck, ... Nov 26 20:57:27 does fsck do "garbage collection"? Nov 26 20:57:34 like, if you forcibly remove a directory entry Nov 26 20:57:38 kerio: indeed I thnk that's what I did in kernel 1.x Nov 26 20:57:40 but the files inside are still there Nov 26 20:57:47 and I laughed my ass off Nov 26 20:57:58 yeah, such fun Nov 26 20:58:05 thanks for reminding me on that episode Nov 26 20:58:14 also, kernel 1? Nov 26 20:58:15 holy shit you're old Nov 26 20:58:23 kerio: fsck will connect disconnected directories/files to /lost+found Nov 26 20:58:28 Pali: ooh right Nov 26 20:58:38 that's what it's for Nov 26 21:03:03 here is that post but is in czech: https://www.abclinuxu.cz/blog/urandom/2011/11/hardlink-na-adresare (but maybe there are other sk/cz people) Nov 26 21:04:05 most important is: directory hardlink to / is really bad idea, it is not possible to unlink it! Nov 26 21:04:16 LOL Nov 26 21:04:22 and it make sense, that unlink is not possible Nov 26 21:04:36 this is totally damaged FS, if you have two inodes which are / Nov 26 21:08:22 is / a particular inode? Nov 26 21:08:43 like, is it always 0 or 1 Nov 26 21:13:47 hm... yes, / is some magic inode... but what fsck can do if it finds more / inodes? Nov 26 21:13:59 stop, drop and roll Nov 26 21:14:14 ok Nov 26 21:14:15 to be fair Nov 26 21:14:24 any entry for / inside a directory is wrong Nov 26 21:14:30 obviously Nov 26 21:14:37 yes Nov 26 21:16:38 https://www.xkcd.com/981/ Nov 26 21:38:18 freemangordon: i have tried a few test with strace -Tttt and -c ... nothing gives a result that could justify a better performance Nov 26 21:38:39 xes: well, the it is a placebo :) Nov 26 21:38:44 *then Nov 26 21:41:09 freemangordon: yes, could be a placebo.. Did you observed some difference? Nov 26 21:41:58 yes, but it might be because of some background activity Nov 26 21:46:03 freemangordon: background activity? Nov 26 21:46:33 yep, someone else yeating CPU cycles and slowing a bit modes Nov 26 21:46:40 *eating Nov 26 21:55:30 btw, other apps are searching for /usr/share/icons/hicolor/icon-theme.cache (for example hildon-status-menu) but that file does not exist. Do you have it? Nov 26 21:56:10 xes: no Nov 26 22:00:24 https://bugs.maemo.org/show_bug.cgi?id=12144 Nov 26 22:00:26 04Bug 12144: Make gtk-update-icon-cache work as advertised Nov 26 22:17:41 freemangordon: this is the latest gtk+2.0 that still has a working gtk-update-icon-cache http://repository.maemo.org/pool/fremantle/free/g/gtk+2.0/libgtk2.0-bin_2.14.7-1maemo12%2b0m5_armel.deb **** ENDING LOGGING AT Wed Nov 27 03:00:00 2013