From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 767D7C433E0 for ; Thu, 23 Jul 2020 09:11:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 367CF22BEF for ; Thu, 23 Jul 2020 09:11:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="iWRjUi5o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 367CF22BEF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 835DD6B0008; Thu, 23 Jul 2020 05:11:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E3FF6B000A; Thu, 23 Jul 2020 05:11:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FAB06B000C; Thu, 23 Jul 2020 05:11:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 55FEB6B0008 for ; Thu, 23 Jul 2020 05:11:54 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C87161858CDE3 for ; Thu, 23 Jul 2020 09:11:53 +0000 (UTC) X-FDA: 77068773306.08.coil55_1b0e4a926f3d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 9A25A1807654A for ; Thu, 23 Jul 2020 09:11:53 +0000 (UTC) X-HE-Tag: coil55_1b0e4a926f3d X-Filterd-Recvd-Size: 3603 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jul 2020 09:11:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595495512; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jOegfAFD7KmRGII6oc4i/sR1c5ZZZGyGt2xHdWoeR1E=; b=iWRjUi5oPgg2ybHq2AFlAinSbwmrHhcO8DAGLpdiH5PRbQPSroSZCRbmBU2y2V3oSL+8YB zUjePOS8guoJL/IN3DBYBaeoujTiK6n1iuHtLh0R7PhlIpqnCIUW7HQmno6BqyKY9HOtQg d5mU1jkB1YiMkD7AnN4zj3h/SbjtBKE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-498-uDp4JBGwN8CN6cCd1mJACw-1; Thu, 23 Jul 2020 05:11:50 -0400 X-MC-Unique: uDp4JBGwN8CN6cCd1mJACw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C11241005504; Thu, 23 Jul 2020 09:11:48 +0000 (UTC) Received: from localhost (ovpn-13-53.pek2.redhat.com [10.72.13.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78D2F2DE68; Thu, 23 Jul 2020 09:11:45 +0000 (UTC) Date: Thu, 23 Jul 2020 17:11:42 +0800 From: Baoquan He To: Anshuman Khandual Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, mike.kravetz@oracle.com, david@redhat.com, akpm@linux-foundation.org Subject: Re: [PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge pages adjustment is not achieved Message-ID: <20200723091142.GR32539@MiWiFi-R3L-srv> References: <20200723032248.24772-1-bhe@redhat.com> <20200723032248.24772-5-bhe@redhat.com> <62c8ce6c-fe98-f371-99b6-cfdb96d1c2fd@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62c8ce6c-fe98-f371-99b6-cfdb96d1c2fd@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Rspamd-Queue-Id: 9A25A1807654A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000046, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 07/23/20 at 11:46am, Anshuman Khandual wrote: > > > On 07/23/2020 08:52 AM, Baoquan He wrote: > > A customer complained that no message is logged wh en the number of > > persistent huge pages is not changed to the exact value written to > > the sysfs or proc nr_hugepages file. > > > > In the current code, a best effort is made to satisfy requests made > > via the nr_hugepages file. However, requests may be only partially > > satisfied. > > > > Log a message if the code was unsuccessful in fully satisfying a > > request. This includes both increasing and decreasing the number > > of persistent huge pages. > > But is kernel expected to warn for all such situations where the user > requested resources could not be allocated completely ? Otherwise, it > does not make sense to add an warning for just one such situation. It's not for just one such situation, we have already had one to warn out in mm/hugetlb.c, please check hugetlb_hstate_alloc_pages(). As Mike said, in one time of persistent huge page number setting, comparing the old value with the new vlaue is good enough for customer to get the information. However, if customer want to detect and analyze previous setting failure, logging message will be helpful. So I think logging the failure or partial success makes sense. Thanks Baoquan