Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Hiroyuki Kamezawa]

On Fri, May 4, 2012 at 5:56 AM, David Rientjes <rientjes@xxxxxxxxxx> wrote:
> On Thu, 3 May 2012, Hiroyuki Kamezawa wrote:
>
>> I think hugetlb should be handled under memcg.

>> 2. The characteristics of hugetlb usage you pointed out is
>> characteristics comes from
>>    "current" implementation.
>>     Yes, it's now unreclaimable and should be allocated by hands of
>> admin. But,
>>     considering recent improvements, memory-defrag, CMA, it can be less
>>     hard-to-use thing by updating implementation and on-demand allocation
>>     can be allowed.
>>
>
> You're describing transparent hugepages which are already supported by
> memcg specifically because they are transparent.

THP just handles hugepages whose size is equal to pgd size. So, hugetlb
is something more than that, it has various sizes.

> I haven't seen any
> proposals on how to change hugetlb when it comes to preallocation and
> mmaping the memory because it would break the API with userspace.
> Userspace packages like hugeadm are actually used in a wide variety of
> places.
>

I just said if users doesn't need to set sysctl, it's more useful. I got similar
claims from users with IPC max params ;) I answerd set it unlimited...


>> 3. If overhead is the problem, and it's better to disable memcg,
>>     Please show numbers with HPC apps. I didn't think memcg has very
>> bad overhead
>>     with Bull's presentation in collaboration summit, this April.
>>
>
> Is this a claim that memory-intensive workloads will have the exact same
> performance with and without memcg enabled?

I wrote that I don't get any report that memcg is too slow and need to be fixed.

I think, in general, once memory is allocated, application will run
faster if it never
free memory. So, good application frees memory in batch when it can do. Because
memcg just adds overheads to memory allocation and unmapping, runtime overhead
tend to be small.
My target number when I started to join memcg developments was 2-3% overheads.

> Even if there's the slightest performance degradation, these are what
> users of hugetlb are concerned with already.  They use hugetlb for
> performance and it would be a shame for it to regress because you have to
> enable memcg.
>

I think such people don't limit any usages....any kinds of
virtualization/resource controls has 0 overheads.

>> 4. I guess a user who uses hugetlbfs will use usual memory at the same time.
>>     Having 2 hierarchy for memory and hugetlb will bring him a confusion.
>>
>
> Cgroups is moving to a single hierarchy for simplification, this isn't the
> only example of where this is currently suboptimal and it would be
> disappointing to solidify hugetlb control as part of memcg because of this
> current limitation that will be addressed by generic cgroups development.
>
> Folks, once these things are merged they become an API that can't easily
> be shifted around and seperated out later.  The decision now is either to
> join hugetlb control with memcg forever when they act in very different
> ways or to seperate them so they can be used and configured individually.

How do other guys think ? Tejun ?

Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/