All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Scott Wood <oss@buserror.net>,
	aneesh.kumar@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 1/5] powerpc/mm/slice: Remove intermediate bitmap copy
Date: Sun, 11 Feb 2018 00:43:09 +1000	[thread overview]
Message-ID: <20180211004309.2eda56a3@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <01e8f783db8f4d4d41df91e0400a8634272b326f.1518226173.git.christophe.leroy@c-s.fr>

On Sat, 10 Feb 2018 13:54:25 +0100 (CET)
Christophe Leroy <christophe.leroy@c-s.fr> wrote:

> bitmap_or() and bitmap_andnot() can work properly with dst identical
> to src1 or src2. There is no need of an intermediate result bitmap
> that is copied back to dst in a second step.

Everyone seems to be working on the slice code all of a sudden. I
had the same change in my series I just posted, but I didn't notice
this one of yours earlier, and it's better split out, so this is
fine by me.

Reviewed-by: Nicholas Piggin <npiggin@gmail.com>

> 
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
>  v2: New in v2
>  v3: patch moved up front of the serie to avoid ephemeral slice_bitmap_copy() function in following patch
>  v4: No change
> 
>  arch/powerpc/mm/slice.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 23ec2c5e3b78..98b53d48968f 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -388,21 +388,17 @@ static unsigned long slice_find_area(struct mm_struct *mm, unsigned long len,
>  
>  static inline void slice_or_mask(struct slice_mask *dst, struct slice_mask *src)
>  {
> -	DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>  	dst->low_slices |= src->low_slices;
> -	bitmap_or(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> -	bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> +	bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
> +		  SLICE_NUM_HIGH);
>  }
>  
>  static inline void slice_andnot_mask(struct slice_mask *dst, struct slice_mask *src)
>  {
> -	DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>  	dst->low_slices &= ~src->low_slices;
>  
> -	bitmap_andnot(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> -	bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> +	bitmap_andnot(dst->high_slices, dst->high_slices, src->high_slices,
> +		      SLICE_NUM_HIGH);
>  }
>  
>  #ifdef CONFIG_PPC_64K_PAGES

  parent reply	other threads:[~2018-02-10 14:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-10 12:54 [PATCH v4 1/5] powerpc/mm/slice: Remove intermediate bitmap copy Christophe Leroy
2018-02-10 12:54 ` [PATCH v4 2/5] powerpc/mm/slice: Enhance for supporting PPC32 Christophe Leroy
2018-02-11 13:59   ` Nicholas Piggin
2018-02-11 15:34     ` Aneesh Kumar K.V
2018-02-11 23:34       ` Nicholas Piggin
2018-02-22 14:24         ` Christophe LEROY
2018-02-12  5:46   ` Aneesh Kumar K.V
2018-02-10 12:54 ` [PATCH v4 3/5] powerpc/mm/slice: Fix hugepage allocation at hint address on 8xx Christophe Leroy
2018-02-10 12:54 ` [PATCH v4 4/5] powerpc/mm/slice: Allow up to 64 low slices Christophe Leroy
2018-02-12  5:47   ` Aneesh Kumar K.V
2018-02-10 12:54 ` [PATCH v4 5/5] powerpc/8xx: Increase number of slices to 64 Christophe Leroy
2018-02-10 14:43 ` Nicholas Piggin [this message]
2018-02-10 14:57   ` [PATCH v4 1/5] powerpc/mm/slice: Remove intermediate bitmap copy Christophe LEROY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180211004309.2eda56a3@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=oss@buserror.net \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.