-----Original Message----- From: ext Anton Vorontsov [mailto:anton.vorontsov@linaro.org] Sent: 08 June, 2012 11:41
...
Right. It but it has drawbacks as well e.g. ensure that daemon scheduled
properly and propagate reaction decision outside ulmkd.
No, ulmkd itself propagates the decision (i.e. it kills processes).
That is a decision "select & kill" :) Propagation of this decision required time. Not all processes could be killed. You may stuck in killing in some cases. ...
In ulmkd I don't use timers at all, and by "watcher" I mean the some userspace daemon that receives lowmemory/pressure events (in our case it is ulmkd).
Thanks for info.
If we start "polling" on /proc/vmstat via userland deferred timers, that would be a single timer, just like in vmevent case. So, I'm not sure what is the difference?..
Context switches, parsing, activity in userspace even memory situation is not changed. In kernel space you can use sliding timer (increasing interval) + shinker.