(2012/05/24 14:16), Andrew Morton wrote: > On Thu, 24 May 2012 10:10:00 +0530 "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > >> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: >> >>> On Tue, 22 May 2012 17:13:11 +0530 >>> "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>