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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7A2EC43334 for ; Wed, 15 Jun 2022 12:33:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 507D76B0071; Wed, 15 Jun 2022 08:33:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B6FE6B0072; Wed, 15 Jun 2022 08:33:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3306A6B0073; Wed, 15 Jun 2022 08:33:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1CC7E6B0071 for ; Wed, 15 Jun 2022 08:33:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E828034570 for ; Wed, 15 Jun 2022 12:33:26 +0000 (UTC) X-FDA: 79580410812.11.1C1354E Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf09.hostedemail.com (Postfix) with ESMTP id DE6E5140084 for ; Wed, 15 Jun 2022 12:33:24 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id o17so10288640pla.6 for ; Wed, 15 Jun 2022 05:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=KYV13fgGLre8uPMLDOQm5AuaXSbMGKMf6dQuecyDzIE=; b=FESMll9aOkfaty25hpn2xP8T16f2E5SiMKIK8MD2Q8MX8ZvAKRLTomfhqT6VfNWG+M cX8nAPRvUaTtYvJTA0P3fmF+zzJ03XB+KtVFvey6e4GMnKQ02YJ5q0IMyiu9uwR5QVdd QJwO8vvy+JXjlFRgah8MxWYYes/kpDE1VbUbfhrBROje3u9ep/320llEuaX9WOxCecpU 7nVKPlbFFi4LjtVtukKJEYFlNQlF7vSTVIYXHBv9j7a1toWVlW1So9RsiW/0RG4sPQ8T XSeDLurTAvqNucYs1VXicsqOUkbhWCiMX8PtZqNpQsdTzdH2Sl8C8ZPXCghkir8GYcCq UlWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=KYV13fgGLre8uPMLDOQm5AuaXSbMGKMf6dQuecyDzIE=; b=SIkzmSN4L0Ix4GVsi9Oq4NlYQHQt5icv9VIJ809yTcMfOiGkhgg6HjzaDQtWApH5Ku GxCsz+BvFPl13JQ45e69+3QKn3wOE79cHVLFhZjAqpAm+PrR6Kvir41bIwpAk3IXLg67 NmuMBlDDUdId2Ddc9K7lyBlfusOCnfOqh51tzISs+ep+4MMdFxfZtviU/yXjHmzH34sc drA67iLwXJT1sQ4DhPTMyUI0uStztgY3p+3dtT4PWmixs76sfxEwqUpigrT+FLzCbLfW YYeZYKvAO/romhE/GTYhLHXwJiMOFxFbdrgwKeF5MIprfz56/RkvRFZvpDFSPzZdLT2F WxxA== X-Gm-Message-State: AJIora9QUdAEN+t4XJueFyVCZSgL53xcin+eMJnAsFxHtKhJ+cMDBoZ1 1pFedr8BSf4bDjuXwO5hQphd3A== X-Google-Smtp-Source: AGRyM1tdnl/wOeuGLVRdWp/163hE3xRu+d14niuWF/eXqr8nGaRlnbrTCAuj9wJF3GUlnmxoZ37Qmg== X-Received: by 2002:a17:902:7085:b0:168:97dc:ddde with SMTP id z5-20020a170902708500b0016897dcdddemr9121500plk.25.1655296403388; Wed, 15 Jun 2022 05:33:23 -0700 (PDT) Received: from localhost ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id g1-20020a17090adac100b001e67e01158fsm1645438pjx.30.2022.06.15.05.33.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 05:33:23 -0700 (PDT) Date: Wed, 15 Jun 2022 20:33:17 +0800 From: Muchun Song To: Mike Kravetz Cc: Oscar Salvador , david@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH 6/6] mm: hugetlb_vmemmap: improve hugetlb_vmemmap code readability Message-ID: References: <20220613063512.17540-1-songmuchun@bytedance.com> <20220613063512.17540-7-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655296406; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KYV13fgGLre8uPMLDOQm5AuaXSbMGKMf6dQuecyDzIE=; b=GCmIRphVU824S01Hl4pPNceD2ih8qC6nmC2g7Scrc9rWgI+fd6EMQOtzgBJK5E/uXMlgeM UdwPnIEG1O+XPVafeKlFOgv+LULOTSnBzblZhq6S2nHYuQ115Z2i9QiYaOT496FKUF36Df h8vwaOLoRz5/TbxyenyQP/CVj/ib+nA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655296406; a=rsa-sha256; cv=none; b=EF+/fm+7lAFmCYiyhNdv5SKIoPiYOh4zO2WF0Y7fK9v6rdjTcmOSwd2rLPBTx6QGaa6d1f ujxcqo5bVXg5h+qHTXfLGVR9NThwFSbzsK0kHxXj7OHlCM4GwXHzqWs5mWEE4mQrlP7Dzh KimPsKFI0PQpAItMfMCZZ3JI1UJwdTY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=FESMll9a; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf09.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=FESMll9a; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf09.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: zxsry4kbgqd3yq31z93zrhtrmfey499f X-Rspamd-Queue-Id: DE6E5140084 X-HE-Tag: 1655296404-306417 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 14, 2022 at 09:57:35AM -0700, Mike Kravetz wrote: > On Tue, Jun 14, 2022 at 12:17:21PM +0800”, Muchun Song wrote: > > On Mon, Jun 13, 2022 at 05:22:30PM -0700, Mike Kravetz wrote: > > > On Mon, Jun 13, 2022 at 05:01:43PM +0800”, Muchun Song wrote: > > > > On Mon, Jun 13, 2022 at 10:33:48AM +0200, Oscar Salvador wrote: > > > > > On Mon, Jun 13, 2022 at 02:35:12PM +0800, Muchun Song wrote: > > > > > BEFORE > > > ------ > > > [ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.19.0-rc1-next-20220610+ root=UUID=49c13301-2555-44dc-847b-caabe1d62bdf ro console=tty0 console=ttyS0,115200 audit=0 transparent_hugepage=always hugetlb_free_vmemmap=on hugepages=512 > > > ... > > > [ 0.330930] HugeTLB: can optimize 4095 vmemmap pages for hugepages-1048576kB > > > [ 0.350450] HugeTLB: can optimize 7 vmemmap pages for hugepages-2048kB > > > [ 0.359282] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages > > > [ 0.359285] HugeTLB registered 2.00 MiB page size, pre-allocated 512 pages > > > > > > AFTER > > > ----- > > > [ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.19.0-rc1-next-20220610+ root=UUID=49c13301-2555-44dc-847b-caabe1d62bdf ro console=tty0 console=ttyS0,115200 audit=0 transparent_hugepage=always hugetlb_free_vmemmap=on hugepages=512 > > > ... > > > [ 0.409068] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages > > > [ 0.409071] HugeTLB registered 2.00 MiB page size, pre-allocated 512 pages > > > [ 1.246107] HugeTLB: 16380 KiB vmemmap can be optimized for a 1.00 GiB page > > > [ 1.246110] HugeTLB: 28 KiB vmemmap can be optimized for a 2.00 MiB page > > > [ 1.246123] HugeTLB: 512 huge pages whose vmemmap are optimized at boot > > > > > > When I read those messages, I am not sure if 'optimized' is the best > > > word to use. I know that using alloc/free throughout the code was > > > confusing. But, wouldn't it perhaps be more clear to the end user if > > > the messages read? > > > > Well, I agree with you at least. "free" may be more friendly to the end > > users. I'll change the word "optimized" to "freed". > > > > > > > > HugeTLB: 16380 KiB vmemmap can be freed for a 1.00 GiB page > > > > > > Also, how about having report_hugepages() call a routine that prints the > > > vmemmmap savings. Then output could then look something like: > > > > > > HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages > > > 16380 KiB vmemmap can be freed for a 1.00 GiB page > > > HugeTLB: registered 2.00 MiB page size, pre-allocated 512 pages > > > 28 KiB vmemmap can be free for a 2.00 MiB page > > > > > > > Well, we eliminate the prefix "HugeTLB:" for memory saving log. > > Maybe it is not a good choice since it it not easy to grep the log > > (e.g. dmesg | grep "HugeTLB" will not show saving log). If > > Agree, we should not drop the HugeTLB prefix from the message. > > > we combine both 2-line log into one line, the log becomes a bit long. > > So I'd like to not eliminate the prefix but gather this 2-line log > > into one place. I mean "HugeTLB: registered 1.00 GiB page size, > > pre-allocated 0 pages" is just followed by "HugeTLB: 28 KiB vmemmap > > can be freed for a 2.00 MiB page" without any log insertion in > > between. But I have no strong opinion do this, I'd likt to listen > > to your opinion before making decision to do those changes. > > I think we are talking about the same thing. Did you make a mistake when > saying amount of vmemmap freed for 2MB page followed 1GB hstate size? > > My thought was that it would be good to log the vmemmap savings near the > message that notes the hstate/huge page size and any precallocation. > Just my opinion. So messages would look like: > > HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages > HugeTLB: 16380 KiB vmemmap can be freed for a 1.00 GiB page > HugeTLB: registered 2.00 MiB page size, pre-allocated 512 pages > HugeTLB: 28 KiB vmemmap can be free for a 2.00 MiB page > I am sure we are on the same page. This looks good to me. > I really do not have strong opinions on this. However, if we are going > to change the messages we should try to make them as useful and clear as > possible. > Make sense. I'll do it in v2. Thanks.