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 A3964C7618A for ; Mon, 20 Mar 2023 15:14:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29A156B0074; Mon, 20 Mar 2023 11:14:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2239A6B007B; Mon, 20 Mar 2023 11:14:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F5576B0074; Mon, 20 Mar 2023 11:14:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EF2176B0074 for ; Mon, 20 Mar 2023 11:14:55 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B6A48AB190 for ; Mon, 20 Mar 2023 15:14:55 +0000 (UTC) X-FDA: 80589624150.22.D5C0FC9 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf08.hostedemail.com (Postfix) with ESMTP id 6779816001E for ; Mon, 20 Mar 2023 15:14:52 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=dyfo88zY; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=+sFPLg9L; spf=pass (imf08.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679325292; 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=uLZs4PB9+G025pPf5iXZq69Oo8p6DwoTDJ9FIB3DakA=; b=cyJU3ObV8VU8AswE7mj/Q7qjOm00Eb3uJ+/prb+ebsyI0shL1GaSTbVgCx8ShoEyKKZ7Y4 mKiyElqNX66sV3QfOnsHZ9QLz2O8ZxADFT6AprJIdCZGp+9Lw/NJyw1br8ktsgy2xgJ3e7 tIVlAxmELW8VVmRcvgOWKepGColn8Bg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=dyfo88zY; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=+sFPLg9L; spf=pass (imf08.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679325292; a=rsa-sha256; cv=none; b=ATYks/31Foa981XMsTUfDp1R+3xhb1NFpYl2Q+dJB55JRlaH8f6UcoVttNqme3YfFk2+rJ Gr5EyETaqfsOXLOaSvOny3M1k0wKIO82I0C9AETi0yBlqtEgyWoPN/0yDVf/pMsCyXZ8Li SwPk61t4JnT7KsSvNlwZYuVY19qcvIM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A1FC221AAD; Mon, 20 Mar 2023 15:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1679325290; h=from:from:reply-to: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; bh=uLZs4PB9+G025pPf5iXZq69Oo8p6DwoTDJ9FIB3DakA=; b=dyfo88zYl6Yg5zwB//QpN0nOKP+K1umn0wM32BDTTjYeqCJ5p9Lw2jOa3SK4qiWcMcrwlj Fy6X5H1yeX38+Va2dUprUcfbeFAEtq8A9KSvKaJDEgyOlLaxVyisCGZWnvVy2frIv5Mm+q gDYPobFxbx1LkmjqgawM9lxRqlfRiho= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1679325290; h=from:from:reply-to: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; bh=uLZs4PB9+G025pPf5iXZq69Oo8p6DwoTDJ9FIB3DakA=; b=+sFPLg9Lj4GgT1NOz/fE/eXtrZorlXjvebBjXnJtiJxzsB8z3hapyRq41TxCT4rp0QOXBH spDHqXlbU7W1nbCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 88EC513A00; Mon, 20 Mar 2023 15:14:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6mHdIGp4GGTcPgAAMHmgww (envelope-from ); Mon, 20 Mar 2023 15:14:50 +0000 Message-ID: <7b2a7b7b-0ebc-1f03-5f1b-ac598fc950dc@suse.cz> Date: Mon, 20 Mar 2023 16:14:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [net PATCH 1/2] mm: Use fixed constant in page_frag_alloc instead of size + 1 Content-Language: en-US From: Vlastimil Babka To: Alexander Duyck , netdev@vger.kernel.org, davem@davemloft.net Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, jannh@google.com References: <20190215223741.16881.84864.stgit@localhost.localdomain> <20190215224412.16881.89296.stgit@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6779816001E X-Stat-Signature: s7xj76feuzxm1smmoeiuk6gho3m4mxaq X-Rspam-User: X-HE-Tag: 1679325292-47851 X-HE-Meta: U2FsdGVkX1/bCulID5XbkJ5cH6QD+iQKBhIdyNCkgf5SR/nsjLLLX29HFiCCc5UOFsy+UQsl0XObs7PP6mOzYV0YCZFcHpLSyGHSG+afHXg1/3KNnTgMk+cU7wN0c2NcfwCtzm4BvZd3lOGpMdkWRRXM8vySZVIGB/2+lBgDU2LeQCbiWMDUH6u3PXk/i+9pLM+wuPNqLTS3eosOaQ9QmDvSuHl7GtXQks+rTM1TdktMVu61tcYPKJeizYzcxSoqNLSQyJu1811AWJN87M+uwPl7Iw1+ZebTeAkPI8GqMQdYEjzhCbOtbKK4vzgvblls0ADGgy7G9o3ObQ3A+PZgbZCYENB80YeTl6x5LOBV3f8WgCjO/IDkJwL0ob0+QL+I+VwxFuStoF5z9fDtsfJhC/+77z4psVtIvxc6u+0KGJG7syE+KX9dHJmWvwiUAcP1Z8RBzRfV5Qbp65EVzjoq2OCVA9WrCmWfjU8PaUUUC45XBXCEzjRc8TbDXzTQPFf/Rgh9ZrHZYHXR3p3EnxacYRFbxBS3mWv1tfO1BlWQ6CAY2aMPQAWRkULsG+7fjP1xBYYQxrV+Ax/Qpiwb2rPd+ZxWGA5t7J7h+rXihJwnh724m/YL9N/kzmrpZOhARoyggHTH3x5sIbosI7f0zaHpvT+wv83g/IwdEq7hc3t/pgJ9dNpN98fhJdg9uF3zubTC7O36VCefajRQAE5Db0kB43Q9ZHQiF0tOovcY7OZ3cpCaImLxw2dF0bVFR/xkd6TQkNrrt3AWIGdChscWV3HoxLHk7hk746QZIicDFXqRQVvo0azNk0iyKJLLpwWL+t4xTmQ3VOOUL6VIJg9tPDkdxJljK8eVM+1uHJPhiIcAMIoXJKv/AoyI7oxh9btRSQEw415Lk4+CKF/xYJ509Ur5TFj5CIgZuBHdRjgJxTLSe+9bq438Jz58C+cJHaM4Sd51Y0CaoiyHj9od3Q1In2A /lgcO30s 0gFw56ot6gwkc2SA5QXQEh5T4GZDCM6ESzJT9vW0en/UqjvlFV5ZqtmFDVBvhi2Zm285V6YzKZl5zHmroYqQW6UqB/mfw+d29LN5/EHrA4uD+/l5xyrGbQX7bEoPfc8xf53lTUv9DeNWBhBGy/IRgFKpjTp3cVeejLAlg5KW0f019AdlUHbfdhfZjWrbWcq4H0WLsd+52zIan0LTzDIdmDUvtoA2u/a0RyiP0RoLa6pme8qqHH7wdpAXBmnvaQH46M4OdcYOY1rd6RFM/Vj+EcdlcytREc7AkR9+PWazO76SkcyX37e0MEnseOb0r5cfLjGxeSl1kLb7g+oRQZ1FkZMhtGPpRGLD4M9O5gS8QWLBJfMR0IhjUwWTdrOzMTXUx/c884LyjspGp2RQBn3rXg7cpBSAmuBBt/qlm 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 2/17/23 10:30, Vlastimil Babka wrote: > On 2/15/19 23:44, Alexander Duyck wrote: >> From: Alexander Duyck >> >> This patch replaces the size + 1 value introduced with the recent fix for 1 >> byte allocs with a constant value. >> >> The idea here is to reduce code overhead as the previous logic would have >> to read size into a register, then increment it, and write it back to >> whatever field was being used. By using a constant we can avoid those >> memory reads and arithmetic operations in favor of just encoding the >> maximum value into the operation itself. >> >> Fixes: 2c2ade81741c ("mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs") >> Signed-off-by: Alexander Duyck >> --- >> mm/page_alloc.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index ebb35e4d0d90..37ed14ad0b59 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -4857,11 +4857,11 @@ void *page_frag_alloc(struct page_frag_cache *nc, >> /* Even if we own the page, we do not use atomic_set(). >> * This would break get_page_unless_zero() users. >> */ >> - page_ref_add(page, size); >> + page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE); > > But this value can be theoretically too low when PAGE_SIZE > > PAGE_FRAG_CACHE_MAX_SIZE? Such as on architectures with 64kB page size, > while PAGE_FRAG_CACHE_MAX_SIZE is 32kB? Nevermind, PAGE_FRAG_CACHE_MAX_SIZE would be 64kB because #define PAGE_FRAG_CACHE_MAX_SIZE __ALIGN_MASK(32768, ~PAGE_MASK) So all is fine, sorry for the noise.