From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbdIMPwj (ORCPT ); Wed, 13 Sep 2017 11:52:39 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:34477 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751123AbdIMPwh (ORCPT ); Wed, 13 Sep 2017 11:52:37 -0400 Date: Wed, 13 Sep 2017 11:52:05 -0400 From: "Liam R. Howlett" To: Michal Hocko 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 Subject: Re: [RFC Patch 1/1] mm/hugetlb: Clarify OOM message on size of hugetlb and requested hugepages total Message-ID: <20170913155204.w75sgaosyqi6it57@oracle.com> 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 References: <20170911154820.16203-1-Liam.Howlett@Oracle.com> <20170911154820.16203-2-Liam.Howlett@Oracle.com> <20170913124258.dipjsogp6vzqyjf4@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170913124258.dipjsogp6vzqyjf4@dhcp22.suse.cz> User-Agent: NeoMutt/20161126 (1.7.1) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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