From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755242AbbITK6e (ORCPT ); Sun, 20 Sep 2015 06:58:34 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:34901 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754514AbbITK6b (ORCPT ); Sun, 20 Sep 2015 06:58:31 -0400 Date: Sun, 20 Sep 2015 12:58:28 +0200 From: Michal Hocko To: Naoya Horiguchi Cc: Andrew Morton , Vlastimil Babka , =?iso-8859-1?Q?P=E1draig?= Brady , David Rientjes , =?iso-8859-1?Q?J=F6rn?= Engel , Mike Kravetz , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Naoya Horiguchi Subject: Re: [PATCH v6 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Message-ID: <20150920105828.GB20562@dhcp22.suse.cz> References: <1442480955-7297-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1442480955-7297-3-git-send-email-n-horiguchi@ah.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442480955-7297-3-git-send-email-n-horiguchi@ah.jp.nec.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 17-09-15 09:09:31, 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. Thank you for making this much more lightweight. If we ever have a request for a per-size breakdown we can add HugetlbPages-$size: value kB > Signed-off-by: Naoya Horiguchi > Acked-by: Joern Engel > Acked-by: David Rientjes Acked-by: Michal Hocko Just a small nit-pick, feel free to ignore if this was really intended: [...] > +static inline void hugetlb_count_add(long l, struct mm_struct *mm) > +{ > + atomic_long_add(l, &mm->hugetlb_usage); > +} > + > +static inline void hugetlb_count_sub(long l, struct mm_struct *mm) > +{ > + atomic_long_sub(l, &mm->hugetlb_usage); > +} I can see why you didn't use dec_mm_counter but the ordering could be same. Other functions which handle counters follow the same template (target, counter/count). -- Michal Hocko SUSE Labs