Re: [PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

(2012/05/24 14:16), Andrew Morton wrote:

> On Thu, 24 May 2012 10:10:00 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Tue, 22 May 2012 17:13:11 +0530
>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>
>>>> Expose the failcnt details to userspace similar to memory and memsw.
>>>
>>> Why?
>>>
>>
>> to help us find whether there was an allocation failure due to HugeTLB
>> limit. 
> 
> How are we to know that is that useful enough to justify expanding the
> kernel API?
> 
> Yes, regular memcg has it, but that isn't a reason.  Do we know that
> people are using that?  That it is useful?
> 
> Also, "cnt" is not a word.  It should be "failcount" or, even better,
> "failure_count".  Or, smarter, "failures".  But we screwed that up a
> long time ago and can't fix it.

It has been there since the first commit of memcg...before I joined.

I sometimes use failcnt to confirm whether an application/benchmark hits
the limit and memory reclaim run by limit or not.

With hugetlb, it has no memory reclaim...'allocation failure by limit'
is informed as -ENOSPC to applications. It seems there 3 reasons of -ENOSPC.
memcg-limit and page-allocation-failure and failure in subpool_get_pages().

I think failcnt may be useful because users may want to know the cause of -ENOSPC
after application exits by seeing -ENOSPC. If failcnt > 0, he will tweak the limit
or check application size. Of course, someone may be able to think of other UI.

Thanks,
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>