[lkml]   [2012]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)
    David Rientjes <> writes:

    >> My first version was to do it as a seperate controller
    >> But the feedback I received was to do it as a part of memcg extension,
    >> because what the controller is limiting is memory albeit a different
    >> type. AFAIU there is also this goal of avoiding controller proliferation.
    > Maybe Kame can speak up if he feels strongly about this, but I really
    > think it should be its own controller in its own file (which would
    > obviously make this discussion irrelevant since mm/hugetlbcg.c would be
    > dependent on your own config symbol). I don't feel like this is the same
    > as kmem since its not a global resource like hugetlb pages are.

    > Hugetlb pages can either be allocated statically on the command line at
    > boot or dynamically via sysfs and they are globally available to whoever
    > mmaps them through hugetlbfs. I see a real benefit from being able to
    > limit the number of hugepages in the global pool to a set of tasks so they
    > can't overuse what has been statically or dynamically allocated. And that
    > ability should be available, in my opinion, without having to enable
    > memcg, the page_cgroup metadata overhead that comes along with it, and the
    > performance impact in using it. I also think it would be wise to seperate
    > it out into its own file at the source level so things like this don't
    > arise in the future.

    All the use cases I came across requested for limiting both memory
    and hugetlb pages. They want to limit the usage of both. So for the use case
    I am looking at memcg will already be enabled.


     \ /
      Last update: 2012-05-03 16:01    [W:0.051 / U:11.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site