From:   Khalid Aziz <gonehacking@gmail.com>
Message-ID: <fa014bc2ddc85363dd6b8d34e9db1301817cb33d.camel@oracle.com>
Subject: Re: [PATCH] mm/pgtable: define pte_index so that preprocessor could
 recognize it
To:     Mike Rapoport <rppt@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Christian Dietrich <stettberger@dokucode.de>,
        Mike Rapoport <rppt@linux.ibm.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Date:   Tue, 11 Jan 2022 11:44:23 -0700
In-Reply-To: <20220111145457.20748-1-rppt@kernel.org>
References: <20220111145457.20748-1-rppt@kernel.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4-1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2022-01-11 at 16:54 +0200, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> Since commit 974b9b2c68f3 ("mm: consolidate pte_index() and
> pte_offset_*()
> definitions") pte_index is a static inline and there is no define for
> it
> that can be recognized by the preprocessor. As the result,
> vm_insert_pages() uses slower loop over vm_insert_page() instead of
> insert_pages() that amortizes the cost of spinlock operations when
> inserting multiple pages.
> 
> Fixes: 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*()
> definitions")
> Reported-by: Christian Dietrich <stettberger@dokucode.de>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Cc: stable@vger.kernel.org
> ---
>  include/linux/pgtable.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index e24d2c992b11..d468efcf48f4 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -62,6 +62,7 @@ static inline unsigned long pte_index(unsigned long
> address)
>  {
>         return (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
>  }
> +#define pte_index pte_index
>  
>  #ifndef pmd_index
>  static inline unsigned long pmd_index(unsigned long address)
> 
> base-commit: 2585cf9dfaaddf00b069673f27bb3f8530e2039c

This is a good fix with positive performance impact.

Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>