Hello Kyungmin, Kyungmin Park [2015-04-21 9:21 +0900]: > At mobile. some daemon is not doing exact daemon task. it acts like > app. so it's kill-able based on priority. now it can't know it's idle > or not. In the app-like daemon developer, they don't want to exit > since performance reason. but in the view of system admin, it's > resource waste. it's better to kill if it know it's idle.
I'm not at all convinced that this is a good strategy. For maximum efficiency you *do* want to let apps stay in RAM/in the background as long as you have enough memory, so that they don't need to re-load/link/initialize when you call them again. So regular time-based sweeps are too aggressive here and lead to unnecessary app starts (which take a lot more CPU/battery than a simple context switch). On the other hand, if you start a new app and it doesn't get enough RAM, you want/need to start killing existing background apps oldest-to-newest (or perhaps biggest-to-smallest) until you have enough RAM again, but that needs to happen immediately. You don't want to wait until the next idle counter timer for this to happen. Finally, waking up the device every 30 s to clean up "idle" apps takes CPU/battery by itself. So I see no use case for idle timer based cleanup. Can you please explain why they are better than on-demand cleanup? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel