On Tue, 02 Dec 2014 15:41:30 -0800 Thiago Macieira <[email protected]>
said:
> On Wednesday 03 December 2014 08:20:46 Carsten Haitzler wrote:
> > > The only way for userspace to get the information is via /proc/*/smaps
> > > and
> > > that is not sufficient. For this daemon to work, we should really get a
> > > kernel feature.
> >
> > we also need events from the kernel. a kernel event saying "help - we are
> > low on memory - please do something now!". otherwise this daemon is left to
> > have to poll and polling is not pretty on power and means the best response
> > time of a "memory shortage" is dependent on polling interval.. and this is
> > an eternal fight between power usage and response. events please.
>
> Agreed. We need that information *before* we run out of memory. When the OOM
> killer triggers, as Dominique said, all hope is probably lost.
>
> A simple implementation of the resource manager could simply monitor
> /proc/meminfo and then notify applications when it thinks resources go low. I
> see problems with that:
>
> 1) polling, like you said
> 2) polling intervals will get higher if the system is out of memory, so a
> runaway application will cause the daemon to fail to report properly
> (you could run it in real-time priority, but this will open another can
> of worms)
> 3) which applications does the manager notify? All of them? Then you trigger
> "thundering herd" problem and you'll probably cause *more* memory to be
> allocated, especially if portions of some of the targeted applications
> had been swapped out or dropped from RSS
> 4) if it's targetting, how will it get the right information? Remember what
> I said about /proc/*/smaps
>
> I think this is an interesting feature, but I think it is one that need to be
> done very carefully.
>
> Oh, by the way, it's too late for 3.0. We're probably talking a 3.1 feature
> here.
or even 4.0.
one option would be that we can configure the kernel to run it's oom killer
algorithm at given levels of "spare memory left" but not actually do the kill -
instead report the pid it WOULD have killed at that point. the kernel would
normally call the oom killer when it hits some critical number of spare pages
of memory (0, 1, 10, 100 - something), so a simple possible solution here would
be to be able to go to some /sys/ file node, and write() a list of spare pages
to call the oom killer at and write() the ascii pid to a sys or something file
that the resource daemon monitors with select. eg:
// configure oom checkpoint to trigger at 20, 100, 500, 2500 and 12500 spare
// pages of memory
int fd = open("/sys/whatever/oom/checkpoints", O_RDWR);
write(fd, "20\n100\n500\n2500\n125000\n", ...);
close(fd);
then open /sys/whatever/oom/checkpointevent (or whatever) and select on it and
when a checkpoint is triggered you get something like:
"500 2376\n"
"2500 12383\n"
etc. - the checkpoint you triggered (you crossed that mark in spare pages), and
the pid that would have been oom killed at that point given oom killer
decisions.
the resource daemon then can decide what to do with that info - yes. it'd have
to run with realtime priority and probably mlock() its memory in place and be
very careful about dynamically allocating more of it.
--
Carsten Haitzler (The Rasterman) <[email protected]>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
