Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: "Liam R. Howlett" Newsgroups: linux.kernel Subject: Re: [RFC Patch 1/1] mm/hugetlb: Clarify OOM message on size of hugetlb and requested hugepages total Date: Wed, 13 Sep 2017 18:00:01 +0200 Message-ID: References: Mail-Followup-To: Michal Hocko , linux-mm@kvack.org, Andrew Morton , Mike Kravetz , Andrea Arcangeli , Naoya Horiguchi , "Kirill A. Shutemov" , Gerald Schaefer , zhong jiang , Hillf Danton , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20161126 (1.7.1) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: robomod@news.nic.it List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Approved: robomod@news.nic.it Lines: 64 Organization: linux.* mail to news gateway X-Original-Cc: linux-mm@kvack.org, Andrew Morton , Mike Kravetz , Andrea Arcangeli , Naoya Horiguchi , "Kirill A. Shutemov" , Gerald Schaefer , zhong jiang , Hillf Danton , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org X-Original-Date: Wed, 13 Sep 2017 11:52:05 -0400 X-Original-Message-ID: <20170913155204.w75sgaosyqi6it57@oracle.com> X-Original-References: <20170911154820.16203-1-Liam.Howlett@Oracle.com> <20170911154820.16203-2-Liam.Howlett@Oracle.com> <20170913124258.dipjsogp6vzqyjf4@dhcp22.suse.cz> X-Original-Sender: linux-kernel-owner@vger.kernel.org Xref: csiph.com linux.kernel:1731693 * Michal Hocko [170913 08:43]: > On Mon 11-09-17 11:48:20, Liam R. Howlett wrote: > > Change the output of hugetlb_show_meminfo to give the size of the > > hugetlb in more than just Kb and add a warning message if the requested > > hugepages is larger than the allocated hugepages. The warning message > > for very badly configured hugepages has been removed in favour of this > > method. > > > > The new messages look like this: > > ---- > > Node 0 hugepages_total=1 hugepages_free=1 hugepages_surp=0 > > hugepages_size=1.00 GiB > > > > Node 0 hugepages_total=1326 hugepages_free=1326 hugepages_surp=0 > > hugepages_size=2.00 MiB > > > > hugepage_size 1.00 GiB: Requested 5 hugepages (5.00 GiB) but 1 hugepages > > (1.00 GiB) were allocated. > > > > hugepage_size 2.00 MiB: Requested 4000 hugepages (7.81 GiB) but 1326 > > hugepages (2.59 GiB) were allocated. > > ---- > > > > The old messages look like this: > > ---- > > Node 0 hugepages_total=1 hugepages_free=1 hugepages_surp=0 > > hugepages_size=1048576kB > > > > Node 0 hugepages_total=1435 hugepages_free=1435 hugepages_surp=0 > > hugepages_size=2048kB > > ---- > > > > Signed-off-by: Liam R. Howlett > > To be honest, I really dislike this. It doesn't really add anything > really new to the OOM report. We already know how much memory is > unreclaimable because it is reserved for hugetlb usage. Why does the > requested size make any difference? We could fail to allocate requested > number of pages because of memory pressure or fragmentation without any > sign of misconfiguration. Okay, thanks. I was trying to address the issues you had with the previous logging addition. I understand that the OOM report is clear to many, but I thought it would be more clear if the hugepage size was printed in a human readable format instead of KB, especially with platforms supporting a lot of huge page sizes and we already use the formatting elsewhere. My thoughts for the requested size was to expose the failure to allocate a resource which currently doesn't have any reporting back to the user - except on boot failures, which you also disliked. I thought reporting in the OOM message would be less of a change than reporting at allocation time and it would be more clear what happened on poorly configured systems as the failure would be printed closer to the panic. > > Also req_max_huge_pages would have to be per NUMA node othwerise you are > just losing information when allocation hugetlb pages via sysfs per node > interface. > Thank you for your thorough review and time, Liam