On Fri, 14 Dec 2007 17:10:50 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled:
> http://www.kuarepoti-dju.net/index.php?p=132 > > According to that article, we're hitting the disk pretty heavily for > writes. Anyone done any investigation on this recently? the reads are e just getting data from the theme. e is always getting data from the theme. when menus pop up with icons, the icons are loaded off disk. they may be in evas's cache, or may not be. they may or may not be in the OS's disk cache. the way he is "debugging" with strace is bad basically. he should do: echo 1 > /proc/sys/vm/block_dump then while [ 1 ]; do sudo dmesg -c ; sleep 1; done this will spew stuff out in the dmesg buffer like: [ 2002.168000] enlightenment(5870): READ block 126091448 on sda3 [ 2002.180000] enlightenment(5870): READ block 126386560 on sda3 [ 2002.180000] enlightenment(5870): READ block 126552520 on sda3 [ 2002.180000] enlightenment(5870): READ block 126713896 on sda3 ... [ 2003.212000] enlightenment(5870): READ block 91226176 on sda3 [ 2003.556000] enlightenment(5870): dirtied inode 8144449 (exebuf_exelist_cache.cfg.tmp) on sda3 [ 2003.556000] enlightenment(5870): dirtied inode 7881209 (?) on sda3 ... [ 2005.232000] pdflush(28129): WRITE block 131858432 on sda3 [ 2005.232000] pdflush(28129): WRITE block 132093648 on sda3 [ 2006.620000] acpid(4659): dirtied inode 359019 (acpid) on sda1 [ 2006.620000] acpid(4659): dirtied inode 359019 (acpid) on sda1 [ 2006.620000] acpid(4659): dirtied inode 359019 (acpid) on sda1 ... [ 2089.388000] enlightenment(5870): dirtied inode 8127044 (profile.cfg.tmp) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8127034 (?) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144465 (module.ibar.cfg.tmp) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144450 (?) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144450 (module.ibox.cfg.tmp) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144456 (?) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144456 (module.pager.cfg.tmp) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144452 (?) on sda3 ... [ 2089.388000] enlightenment(5870): dirtied inode 8144455 (module.fileman.cfg.tmp) on sda3 [ 2089.388000] enlightenment(5870): dirtied inode 8144464 (?) on sda3 [ 2089.512000] enlightenment(5870): dirtied inode 8144464 (e.cfg.tmp) on sda3 [ 2089.512000] enlightenment(5870): dirtied inode 8144448 (?) on sda3 ... [ 3034.244000] enlightenment(5870): dirtied inode 8144453 (exehist.cfg.tmp) on sda3 [ 3034.248000] enlightenment(5870): dirtied inode 8144448 (?) on sda3 etc. - you get the idea. this allows you to see where REAL disk activity is coming from/going to (if it only accesses files in disk cache they will not be dumped as disk accesses here). now - this bits about accessing the acpi governor stuff and theme stuff. theme stuff - that data e needs to display anything. it probably should be in disk cache after a while then spin down. i have considered adding some things to eet etc. etc. to have a "laptop mode" where any eet file the first time it is seen by eet (app tries to open it) and it hasn't changed since the last time, has all of the file read() into ram thus populating disk cache. this should very quickly fill disk cache on the system with these read-only data files and limit/stop disk activity later on (unless they get flushed from cache). the acpi governor stuff. this is /proc and /sys stuff - the battery module does this too. its a virtual fs, not real. the guy doesn't seem to know this and thus thinks these accesses are not needed. they are used by cpufreq, battery, temperature etc. modules to get system stats for display - don't like it? disable the module. you don't have much of a choice here - you need to get that info to display it and need to update it. we could use the dbus power management api - but then a dbus service just does the same thing anyway. either way - it doesn't ever touch the actual disk, so it's not relevant to disk spinup/down discussions (but it relevant in that we do ask the kernel for info regularly some accesses to /proc or /sys info can sometime be "expensive"). now the writes - i've done this before. as above all the writes are literally e SAVING its config. e is aggressive in saving its config. if anything changes to its config that e might want to save, it literally calls e_config_save_queue() to queue a save. this, to minimise insane disk writes and overhead, delays the save by 0.25 seconds (if any other config change/save queue happens within these 0.25 seconds then it just gets delayed again until things settle down).THEN the config is saved. if e doesn't think there is anything to save, it won't. calls to e_config_save_queue() make e think things need saving. it doesn't do anything like examine the config as a "diff" and actually see if any changes did happen. it simply blindly saves as above if e_config_save_queue() is called. so e's writes are valid - it is saving state. remember e SAVES a list of every executable you ever ran via E and when - what app. it uses this for exebuf to order search results to use the most recent/commonly used apps. e saves config because the config stores "remembered" properties for windows. move/resize any window that is marked for being remembered in any way, e will queue a config save as any changes to that window will now need saving. now here comes the catch. yes - we could delay saves much longer in a "laptop mode" style. no problems. BUT. this means that if e segv's or is killed before it manages to save its conifg, you lose any changes. that is why its aggressive at saving - so these are not lost. e will also flush a save on exit (if it exits or restarts cleanly). it's a give and take. there is no config swizzle knob for this - though it'd be easy to add. the problem is that we will lose stuff - given that e isn't stable yet - this will be bad. there is no major design flaw or issue with e here at all actually. try it for yourself and check the actual disk access (read or write) stats when you get them from the kernel properly. as i said - we can make e load (pre-seed the cache) data it knows it may need (eg all the .edj files for theme(s) it knows it will need, all the icon files for every .desktop file efreet finds, etc. etc.) and that should put an end to actual reads - the reads will end eventually once you have accessed enough of this data anyway. this can be thwarted by disk cache cycling (so we could regularly do this every 30 seconds or whatever to just keep the disk cache fresh and populated), but i consider this moot if you actually see the disk reads by most other processes, applications and utilities, e is no worse than any of them - in fact its generally better as it keeps its accesses more limited due to edje and evas's own userspace caching. we can make saves of config less aggressive by simply changing a value (0.25 can become 3600 or whatever to delay saves), but there is a cost when you get killed or crash. i see no fundamental issue here. what would be better here is to DETECT "laptop mode" (i.e. if on a device with a battery and the device loses its AC power), then have these 2 things change based on AC power state. that would be the right way to do these and so users dont need to specially configure things - it would do what most people want automatically (of courser allow to disable this and force one or the other mode all the time, or base going into laptop mode on combinations of AC power state plus battery level etc.). all in all - it's not a big issue - and it is one i have actually looked at before - in detail. so... suggestions are welcome? (frankly the guy could limit his disk writes by setting his kernel vfs to delay writes when in laptop mode more. he should check his laptop-mode.conf and fix it up to really aggressively avoid real disk writes and keep fs writes/changes in cache much longer. of course then HE runs the risk of losing writes/changes should his machine crash/lose power etc... same problem again... -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
