[lkml]   [2012]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.
    On 03/13/2012 09:00 PM, Greg Thelen wrote:
    > Glauber Costa<> writes:
    >> 2) For the kernel itself, we are mostly concerned that a malicious container may
    >> pin into memory big amounts of kernel memory which is, ultimately,
    >> unreclaimable. In particular, with overcommit allowed scenarios, you can fill
    >> the whole physical memory (or at least a significant part) with those objects,
    >> well beyond your softlimit allowance, making the creation of further containers
    >> impossible.
    >> With user memory, you can reclaim the cgroup back to its place. With kernel
    >> memory, you can't.
    > In overcommit situations the page allocator starts failing even though
    > memcg page can charge pages.
    If you overcommit mem+swap, yes. If you overcommit mem, no: reclaim
    happens first. And we don't have that option with pinned kernel memory.

    Of course you *can* run your system without swap, but the whole thing
    exists exactly because there is a large enough # of ppl who wants to be
    able to overcommit their physical memory, without failing allocations.

     \ /
      Last update: 2012-03-13 18:35    [W:4.043 / U:0.212 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site