lkml.org 
[lkml]   [2012]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
    On Wed, Nov 07, 2012 at 03:43:46AM -0800, Anton Vorontsov wrote:
    > On Wed, Nov 07, 2012 at 01:21:36PM +0200, Kirill A. Shutemov wrote:
    > [...]
    > > Sorry, I didn't follow previous discussion on this, but could you
    > > explain what's wrong with memory notifications from memcg?
    > > As I can see you can get pretty similar functionality using memory
    > > thresholds on the root cgroup. What's the point?
    >
    > There are a few reasons we don't use cgroup notifications:
    >
    > 1. We're not interested in the absolute number of pages/KB of available
    > memory, as provided by cgroup memory controller. What we're interested
    > in is the amount of easily reclaimable memory and new memory
    > allocations' cost.
    >
    > We can have plenty of "free" memory, of which say 90% will be caches,
    > and say 10% idle. But we do want to differentiate these types of memory
    > (although not going into details about it), i.e. we want to get
    > notified when kernel is reclaiming. And we also want to know when the
    > memory comes from swapping others' pages out (well, actually we don't
    > call it swap, it's "new allocations cost becomes high" -- it might be a
    > result of many factors (swapping, fragmentation, etc.) -- and userland
    > might analyze the situation when this happens).
    >
    > Exposing all the VM details to userland is not an option

    IIUC, you want MemFree + Buffers + Cached + SwapCached, right?
    It's already exposed to userspace.

    > -- it is not
    > possible to build a stable ABI on this. Plus, it makes it really hard
    > for userland to deal with all the low level details of Linux VM
    > internals.
    >
    > So, no, raw numbers of "free/used KBs" are not interesting at all.
    >
    > 1.5. But it is important to understand that vmpressure_fd() is not
    > orthogonal to cgroups (like it was with vmevent_fd()). We want it to
    > be "cgroup'able" too. :) But optionally.
    >
    > 2. The last time I checked, cgroups memory controller did not (and I guess
    > still does not) not account kernel-owned slabs. I asked several times
    > why so, but nobody answered.

    Almost there. Glauber works on it.

    --
    Kirill A. Shutemov


    \
     
     \ /
      Last update: 2012-11-07 13:41    [W:6.926 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site