Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mPwdz-0005gm-Qe for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Sep 2021 00:49:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mPwdy-0001NS-Eu for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Sep 2021 00:49:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mPwdy-0001Lg-5J for pgsql-hackers@lists.postgresql.org; Tue, 14 Sep 2021 00:49:50 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mPwdr-0000RA-QF for pgsql-hackers@postgresql.org; Tue, 14 Sep 2021 00:49:49 +0000 Received: by mail-pj1-x1029.google.com with SMTP id dw14so6743299pjb.1 for ; Mon, 13 Sep 2021 17:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=Z2ktNaC6p6pivZjO8Ni8YXuj6tPxHaNdUEgIiVtsS3k=; b=QV+YSQ72fu5CIJkr3GEg+toNipkz069SKUk5P7nuzgN5Nvs2VGpwPAnAm9smj0S0Sg YTQQf17A81yFHnsqpJ/qKtNFxeDWSNuuQapGdOUGbflpBAhG0tGa1nd2JMYmMZi1cpek fLIIvd6Gtl70tfV3fOJHgLOCK9hNT71I1733LTam2/TBK2Uwc6DY+bNovr3V/dG842Mb 3rOpoCydYeCpvfOXAFoSuX1m18lA8sAIE0TFalGKQszvfc9z09XqJ7OqfeDjG1GO/Pzl lCd1JCzoaoAUegIzsxzrBIJyCGrLs/iO9qNCg91PHf1UGMiN1UVN19+RlSTU2UXo5cM8 fpmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Z2ktNaC6p6pivZjO8Ni8YXuj6tPxHaNdUEgIiVtsS3k=; b=fYPOK13fe6mMO4JzucipfrOFlWp1dn7ZbLcTuwOb3QmzHaMFQhaQofSalvH0gVX1hN 0e8p47XilXY+JPq7f4vmyFDdN9pzDFSyp3dF7YgsWMS+plkJkeLdLUzzyaExFxKmfINj 5CKbbr2EUltFQ0KqPCRMkD/OkGJfsRibeW2s2+yLGVKc6tZP/DoRYLoHIcparE7TZT3f Z4Ag4b0GfjPf9fh1JcQcDS2lu7/sP3NpKQvzCjy8QwR2vrZbUaw+tfzT1clQDlVp9lbQ 9lxWOISCWyafbxj7PnPerV215dszTa6JD6XEL/Xe4I7/WMgPJVWWs73zg9+o2P92GPkZ FjfA== X-Gm-Message-State: AOAM5320JlGMBJj3zgbRgR0UuLBxk5pKRWs6EKuTf5+l15aT4KiQ++Ge f5PYEF8NyoQZ4kXa+K2tKJA= X-Google-Smtp-Source: ABdhPJzEAvwd/OtBdlzofqYkdq0vtCijYx8rszuZxlO9ugtpAgeKZ1K6bT+HAyW8AvuspIXrA9faMA== X-Received: by 2002:a17:902:f54e:b0:13b:8ac4:5d95 with SMTP id h14-20020a170902f54e00b0013b8ac45d95mr9264507plf.8.1631580582051; Mon, 13 Sep 2021 17:49:42 -0700 (PDT) Received: from localhost (sp49-97-107-208.msc.spmode.ne.jp. [49.97.107.208]) by smtp.gmail.com with ESMTPSA id u24sm8303837pfm.85.2021.09.13.17.49.38 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 13 Sep 2021 17:49:41 -0700 (PDT) Date: Tue, 14 Sep 2021 09:49:36 +0900 (JST) Message-Id: <20210914.094936.565951707453489109.horikyota.ntt@gmail.com> To: bossartn@amazon.com Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, michael@paquier.xyz, masao.fujii@oss.nttdata.com, pryzby@telsasoft.com, andres@anarazel.de, magnus@hagander.net, mark.dilger@enterprisedb.com, don@seiler.us, pgsql-hackers@postgresql.org Subject: Re: Estimating HugePages Requirements? From: Kyotaro Horiguchi In-Reply-To: References: <506431.1631564654@sss.pgh.pa.us> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Tue, 14 Sep 2021 00:30:22 +0000, "Bossart, Nathan" wrote in > On 9/13/21, 1:25 PM, "Tom Lane" wrote: > > Seems like "huge_pages_needed_for_shared_memory" would be sufficient. > > I think we are down to either shared_memory_size_in_huge_pages or > huge_pages_needed_for_shared_memory. Robert's argument against > huge_pages_needed_for_shared_memory was that it might sound like only > part of shared memory uses huge pages and we're only giving the number > required for that. Speaking of which, isn't that technically true? > For shared_memory_size_in_huge_pages, the intent is to make it sound > like we are providing shared_memory_size in terms of the huge page > size, but I think it could also be interpreted as "the amount of > shared memory that is currently stored in huge pages." > > I personally lean towards huge_pages_needed_for_shared_memory because > it feels the most clear and direct to me. I'm not vehemently opposed > to shared_memory_size_in_huge_pages, though. I don't think either one > is too misleading. I like 'in' slightly than 'for' in this context. I stand by Michael that that name looks somewhat too long especially considering that that name won't be completed on shell command lines, but won't fight it, too. On the other hand the full-spelled name can be thought as one can spell it out from memory easily than a name halfway shortened. regards. -- Kyotaro Horiguchi NTT Open Source Software Center