linux-kernel - memcg cgroup controller & sbrk interaction

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-next>] [day] [month] [year] [list]

Message-ID: <1339118347.78794.YahooMailNeo@web112018.mail.gq1.yahoo.com>
Date:	Thu, 7 Jun 2012 18:19:07 -0700 (PDT)
From:	Ron Chen <ron_chen_123@...oo.com>
To:	Linux Mailing List <linux-kernel@...r.kernel.org>
Subject: memcg cgroup controller & sbrk interaction

We are from the Open Grid Scheduler, which is the official Open Source Grid Engine. Open Grid Scheduler/
Grid Engine ( http://gridscheduler.sourceforge.net ) is used by many compute farms & HPC sites for job scheduling.

In the next release, we are using cgroups to define a Job Container interface for batch jobs:

http://blogs.scalablelogic.com/2012/05/grid-engine-cgroups-integration.html

However, not only us, but others have found that the memcg controller does not cause sbrk(2) or mmap(2) to
return error when the cgroup is under high memory pressure. Further, when the amount of free memory is
really low, the Linux Kernel OOM killer picks something and kills it.

http://www.spinics.net/lists/cgroups/msg02622.html

We also would like to see if it is technically possible for the Virtual Memory Manager to interact with the
memory controller properly and give us the semantics of setrlimit(2). So basically if the current address
space usage exceeds the "memory.memsw.limit_in_bytes" limit defined by the administrator, then the
memory allocation system calls (example: mmap(2), sbrk(2), etc) will return error such that the OOM
killer is not invoked.

Thanks in advance.

 -Ron
--
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/