linux-kernel - Re: [PATCH 2/5] vmevent: Convert from deferred timer to deferred work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Jun 2012 01:41:06 -0700
From:	Anton Vorontsov <anton.vorontsov@...aro.org>
To:	leonid.moiseichuk@...ia.com
Cc:	kosaki.motohiro@...il.com, penberg@...nel.org,
	b.zolnierkie@...sung.com, john.stultz@...aro.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	kernel-team@...roid.com
Subject: Re: [PATCH 2/5] vmevent: Convert from deferred timer to deferred work

On Fri, Jun 08, 2012 at 08:16:04AM +0000, leonid.moiseichuk@...ia.com wrote:
> > -----Original Message-----
> > From: ext Anton Vorontsov [mailto:anton.vorontsov@...aro.org]
> > Sent: 08 June, 2012 10:59
> ... 
> > a) Two more context swtiches;
> > b) Serialization/deserialization of /proc/vmstat.
> > 
> > > It also will cause page trashing because user-space code could be pushed
> > out from cache if VM decide.
> > 
> > This can solved by moving a "watcher" to a separate (daemon) process, and
> > mlocking it. We do this in ulmkd.
> 
> 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).

Here is how it works:

1. Android activity manager (it is tons of Java-code, runs inside a
   JVM) maintains list of applications and their "importance" index.
   This huge pile of code (and the whole JVM) of course can't be
   mlocked, and so it only maintains the list.

2. Once ulmkd (a separate low memory killer daemon, written in C)
   receives notification that system is low on memory, then it looks 
   at the already prepared lists, and based on the processes'
   importance (and current free memory level) it kills appropriate
   apps.

Note that in-kernel LMK does absolutely the same as ulmkd, just
in the kernel (and the "importance index" is passed to LMK as
per-process oom_score_adj).

> Also I understand your statement about "watcher" as probably you use one timer for daemon. 
> Btw, in my variant (memnotify.c) I used only one timer, it is enough.

Not quite following.

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).

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?..

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/