Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752946AbbHTXiM (ORCPT ); Thu, 20 Aug 2015 19:38:12 -0400 Received: from TYO202.gate.nec.co.jp ([210.143.35.52]:50656 "EHLO tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbbHTXiK (ORCPT ); Thu, 20 Aug 2015 19:38:10 -0400 From: Naoya Horiguchi To: Michal Hocko CC: Andrew Morton , David Rientjes , =?utf-8?B?SsO2cm4gRW5nZWw=?= , Mike Kravetz , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Naoya Horiguchi Subject: Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Thread-Topic: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Thread-Index: AQHQ2yHoV0QXX6xP10iLFfDQGG5gpJ4UIZmAgADS4AA= Date: Thu, 20 Aug 2015 23:34:51 +0000 Message-ID: <20150820233450.GB10807@hori1.linux.bs1.fc.nec.co.jp> References: <20150812000336.GB32192@hori1.linux.bs1.fc.nec.co.jp> <1440059182-19798-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1440059182-19798-3-git-send-email-n-horiguchi@ah.jp.nec.com> <20150820110004.GB4632@dhcp22.suse.cz> In-Reply-To: <20150820110004.GB4632@dhcp22.suse.cz> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.16] Content-Type: text/plain; charset="utf-8" Content-ID: <7382E480AE244F4CB53C740BEE242B42@gisp.nec.co.jp> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t7KNcGjr030689 Content-Length: 987 Lines: 19 On Thu, Aug 20, 2015 at 01:00:05PM +0200, Michal Hocko wrote: > On Thu 20-08-15 08:26:27, Naoya Horiguchi wrote: > > Currently there's no easy way to get per-process usage of hugetlb pages, > > Is this really the case after your previous patch? You have both > HugetlbPages and KernelPageSize which should be sufficient no? We can calcurate it from these info, so saying "no easy way" was incorrect :( > Reading a single file is, of course, easier but is it really worth the > additional code? I haven't really looked at the patch so I might be > missing something but what would be an advantage over reading > /proc//smaps and extracting the information from there? My first idea was just "users should feel it useful", but permission as David commented sounds a good technical reason to me. Thanks, Naoya Horiguchi????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?