On Sat, 24 Aug 2024 16:24:13 +0900 Masaru Nomiya <nom...@lake.dti.ne.jp> said:
What bug? efreetd when it starts needs to scan all your desktop files, icon themes etc. to check that they have not changed. it will issue an update event when done. if this takes too long, enlightenment gets impatient and complains assuming something is probably wrong. they may take too long if you have a lot of desktop files or icon themes installed (on the system or n your user directories). if you have a very slow disk it will take longer. if you have a slow cpu, building the data structures and writing them out will also take longer. nothing has changed here. if you modify files anywhere in the desktop files dirs or icon themes, then efreetd will launch another "rebuild cache" process. grep for efreetd processes. if you have a slow disk and something keeps modifying these dirs causing lots of rebuilds AND it also consumes lots of disk i/o too then there may be competition for disk i/o. if you have a HDD not a SSD then this will be a LOT of contention on seeking. you system freezing might be due to the large amount of i/o and with mmaped data being kicked out of disk cache and needing to be re-loaded back in and this stalls E when this happens. there isn't anything E can do about this - it has binaries, libraries and data files mmaped into memory and if the kernel throws these pages out because it wants to use them for other i/o and these pages are needed again, then they have to be paged in. the slower the disk is to do this, the more of a stall you will get. the commit you point to specifically removes ppc assembly in efl - it will not affect anyone who is not on ppc. also it's only in the yuv->rgb conversion code thus only affects video playback. evas will also then use it's regular c implementation of this code anyway so it may be a bit less efficient at it, but will otherwise work. as ppc is essentially dead other than on ibm power systems, this is not really a loss. there's a bug in the ppc asm and as i have no ppc hw and it's pretty hard to come by, i'm not going to fix it, so removing it is the best solution, but as i said - its not relevant to efreetd. from your top output nothing from efl (enlightenment, not efreetd or anything) us using any significant cpu nor any significant amount of ram. it could have been the efreetd cache create processes (efreet_icon_cache_createm efreet_desktop_cache_create or even efreet_mime_cache_Create) and you'd see these churning away. iotop might show you the processes fighting over disk i/o at the time. i suspect whatever was happening to your backup wasn't to do with efl or e and just happened to be something going on at the time. going back commits didn't change anything relevant in efl - it just changed the situation that now you don't have some kind of contention over disk etc. > Hello, > > I am using recoll and I backup my db to an external USB HDD every > weekend. > > total 138493172 > drwxr-xr-x 1 masaru masaru 170 Aug 24 14:46 . > drwx------ 1 masaru masaru 272 Feb 1 2024 .. > -rw-r--r-- 1 masaru masaru 4082475008 Aug 24 14:35 docdata.glass > -rw-r--r-- 1 masaru masaru 0 Aug 24 14:35 flintlock > -rw-r--r-- 1 masaru masaru 195 Aug 24 14:46 iamglass > -rw-r--r-- 1 masaru masaru 88162557952 Aug 24 14:35 position.glass > -rw-r--r-- 1 masaru masaru 28795674624 Aug 24 14:46 postlist.glass > -rw-r--r-- 1 masaru masaru 143237120 Aug 24 14:46 synonym.glass > -rw-r--r-- 1 masaru masaru 20633059328 Aug 24 14:35 termlist.glass > > However, since August 3, the system started to freeze when taking > backups, and sometimes the enlightenment screams and it takes more > than 2 hours to take backups. > > E:Efreet did not update cache. > Please check your EFreet setup. > Is efreetd running? > Can ~/.cache/efreet be written to? > > where efreetd was running and ~/.cache/efreet was fine. > > On August 3, there was a kernel update from 6.9.9 to 6.10.1, and I > suspected kernel 6.10.x because khugepage and kswapd0 appeared to be > resident in the working top command, as shown below; > > %Cpu(s): 0.3 us, 22.2 sy, 0.0 ni, 77.4 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 > st MiB Mem : 96311.20+total, 1430.219 free, 8710.281 used, > 90541.09+buff/cache MiB Swap: 96311.20+total, 96306.45+free, 4.750 used. > 87600.92+avail Mem > > 687 root 20 0 0 0 0 R 56.29 0.000 31:37.58 > btrfs-c+ 137 root 39 19 0 0 0 R 100.0 0.000 43:17.86 > khugepa+ 154 root 20 0 0 0 0 R 100.0 0.000 122:26.53 > kswapd0 112513 root 25 5 12264 2508 1308 R 99.34 0.003 86:48.69 > rsync 687 root 20 0 0 0 0 R 51.99 0.000 31:39.15 > btrfs-c+ 141292 masaru 15 -5 244428 65596 46000 S 3.311 0.067 > 0:00.10 emacs 139385 masaru 20 0 841584 172052 86332 S 2.318 0.174 > 1:02.58 enlight+ 106177 root 20 0 24.270g 161500 87148 S 1.656 0.164 > 17:36.16 Xorg.bin [...] > > However, I could not find any reports of a kernel 6.10 problem, so I > checked and found the following description, and reverted efl to > 64e20e8a80be01fd612baaae99463beb2af4a96b. > > Date: Fri Aug 2 09:59:38 2024 +0100 > > remove ppc altivec yuv to rgb as it was broken anyway > > i have no pcc hw and it seems no one who has any cares enough to run > and test this stuff and/or fix it... so best path - remove it and > rely on the generic c fallbacks and be a bit slower. > > fixes #68 > > @fix > > commit 64e20e8a80be01fd612baaae99463beb2af4a96b > > Then I made a backup of the recoll db and finished the work in less > than 20 minutes without causing any system problems. > > >From the above, I believe that there is a bug in the current efl due > to the change in Date: Fri Aug 2 09:59:38 2024 +0100, am I wrong? > > Best Regards. > > --- > ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp > ┃＼／彡 > ┗━━┛ "Distinguish between what is meaningful to me and what is meaningless, > and forget what is meaningless to me. This is where individuality > comes into play. This is a function that computer cannot perform." > > -- Shigehiko Toyama (in Japanes) > -- > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
