On Thu 07-01-16 20:26:32, Guido Trentalancia wrote:
> Hello Michal.
>
> I believe it's a serious problem, as an unprivileged user-space
> application can basically render the system completely unusable, so
> that it must be hard-rebooted.
Unfortunatelly there are many other ways how your user can consume a lot
of memory without some way of memory containment. E.g. memory cgroups
can help in that regards.
[...]
> > > Dec 29 12:28:25 vortex kernel: Killed process 10197 (cc1plus)
> > > total-vm:969632kB, anon-rss:809184kB, file-rss:9308kB
> >
> > This task is consuming a lot of memory so killing it should help to
> > release the memory pressure. It would be interesting to see whether
> > the
> > task has died or not.
>
> I am not able to login into any console and therefore I cannot check
> whether the gcc task died or not.
sysrq is not an option?
> > Are there any follow up messages in the log?
>
> The first message have been posted entirely. Such message is then
> repeated several times (for the "cc1plus" task and once for the "as"
> assembler). The other messages are similar and therefore have not been
> posted...
A full kernel log is usually more interesting to see the timing and
other information (e.g. how much has the situation changed after the OOM
killer invocation).
> It only appears to happen with parallel builds ("make -j4") and not
> with normal builds ("make" or "make -j1"), but that's another issue,
This could mean that the memory got so fragmented that a larger fork
load which requires higher order allocations can trigger OOM killer.
Your OOM report talks about order-0 request triggering the OOM killer
but higher parallel load might contribute
> I mean a user-space application should not be able to render the
> system unusable by sucking all of its memory...
>
> Is the hard-disk working continuosly because the kernel is trying to
> swap endlessly and cannot reclaim back memory ?!?
I would suspect page cache trashing to be a more probable reason. As
already pointed out your swap space is full and so the anonymous memory
which is the largest contributor to the memory consumption cannot be
reclaimed. So all you get is to reclaim the page cache and your load
will likely need more of it then would fit into the remaining memory.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>