Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752034AbbHLUab (ORCPT ); Wed, 12 Aug 2015 16:30:31 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:35569 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbbHLUa3 (ORCPT ); Wed, 12 Aug 2015 16:30:29 -0400 Date: Wed, 12 Aug 2015 13:30:27 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Naoya Horiguchi cc: Andrew Morton , =?UTF-8?Q?J=C3=B6rn_Engel?= , Mike Kravetz , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Naoya Horiguchi Subject: Re: [PATCH v4 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status In-Reply-To: <1439365520-12605-2-git-send-email-n-horiguchi@ah.jp.nec.com> Message-ID: References: <20150812000336.GB32192@hori1.linux.bs1.fc.nec.co.jp> <1439365520-12605-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1439365520-12605-2-git-send-email-n-horiguchi@ah.jp.nec.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1650 Lines: 39 On Wed, 12 Aug 2015, Naoya Horiguchi wrote: > Currently there's no easy way to get per-process usage of hugetlb pages, which > is inconvenient because userspace applications which use hugetlb typically want > to control their processes on the basis of how much memory (including hugetlb) > they use. So this patch simply provides easy access to the info via > /proc/PID/status. > > With this patch, for example, /proc/PID/status shows a line like this: > > HugetlbPages: 20480 kB (10x2048kB) > > If your system supports and enables multiple hugepage sizes, the line looks > like this: > > HugetlbPages: 1069056 kB (1x1048576kB 10x2048kB) > > , so you can easily know how many hugepages in which pagesize are used by a > process. > > Signed-off-by: Naoya Horiguchi I'm happy with this and thanks very much for going the extra mile and breaking the usage down by hstate size. I'd be interested in the comments of others, though, to see if there is any reservation about the hstate size breakdown. It may actually find no current customer who is interested in parsing it. (If we keep it, I would suggest the 'x' change to '*' similar to per-order breakdowns in show_mem()). It may also be possible to add it later if a definitive usecase is presented. But overall I'm very happy with the new addition and think it's a good solution to the problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/