[lkml]   [2006]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ckrm-tech] RFC: Memory Controller
    Pavel Emelianov wrote:
    > Balbir Singh wrote:
    >> Pavel Emelianov wrote:
    >>> [snip]
    >>>> Reclaimable memory
    >>>> (i) Anonymous pages - Anonymous pages are pages allocated by the user space,
    >>>> they are mapped into the user page tables, but not backed by a file.
    >>> I do not agree with such classification.
    >>> When one maps file then kernel can remove page from address
    >>> space as there is already space on disk for it. When one
    >>> maps an anonymous page then kernel won't remove this page
    >>> for sure as system may simply be configured to be swapless.
    >> Yes, I agree if there is no swap space, then anonymous memory is pinned.
    >> Assuming that we'll end up using a an abstraction on top of the
    >> existing reclaim mechanism, the mechanism would know if a particular
    >> type of memory is reclaimable or not.
    > If memory is considered to be unreclaimable then actions should be
    > taken at mmap() time, not later! Rejecting mmap() is the only way to
    > limit user in unreclaimable memory consumption.

    That's like disabling memory over-commit in the regular kernel.
    Don't you think this should again be based on the systems configuration
    of over-commit?


    >> I understand that kernel memory accounting is the first priority for
    >> containers, but accounting kernel memory requires too many changes
    >> to the VM core, hence I was hesitant to put it up as first priority.
    > Among all the kernel-code-intrusive patches in BC patch set
    > kmemsize hooks are the most "conservative" - only one place
    > is heavily patched - this is slab allocator. Buddy is patched,
    > but _significantly_ smaller. The rest of the patch adds __GFP_BC
    > flags to some allocations and SLAB_BC to some kmem_caches.
    > User memory controlling patch is much heavier...

    Please see the patching of Rohit's memory controller for user
    level patching. It seems much simpler.

    > I'd set priorities of development that way:
    > 1. core infrastructure (mainly headers)
    > 2. interface
    > 3. kernel memory hooks and accounting
    > 4. mappings hooks and accounting
    > 5. physical pages hooks and accounting
    > 6. user pages reclamation
    > 7. moving threads between beancounters
    > 8. make beancounter persistent

    I would prefer a different set

    1 & 2, for now we could use any interface and then start developing the
    controller. As we develop the new controller, we are likely to find the
    need to add/enhance the interface, so freezing in on 1 & 2 might not be
    a good idea.

    I would put 4, 5 and 6 ahead of 3, based on the changes I see in Rohit's
    memory controller.

    Then take up the rest.


    Balbir Singh,
    Linux Technology Center,
    IBM Software Labs
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-31 11:57    [W:0.025 / U:46.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site