From: Segher Boessenkool <segher@kernel.crashing.org>
To: Christophe LEROY <christophe.leroy@c-s.fr>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Scott Wood <oss@buserror.net>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32
Date: Tue, 23 Jan 2018 15:47:00 -0600 [thread overview]
Message-ID: <20180123214659.GG21977@gate.crashing.org> (raw)
In-Reply-To: <52c000dd-1625-a205-8ad1-04376beed2ab@c-s.fr>
On Mon, Jan 22, 2018 at 08:52:53AM +0100, Christophe LEROY wrote:
> >Just make sure to declare all functions, or define it to some empty
> >thing, or #ifdeffery if you have to. There are many options, it is
> >not hard, and if it means you have to pull code further apart that is
> >not so bad: you get cleaner, clearer code.
>
> Ok, if I understand well, your comment applies to the following indeed,
> so you confirm the #ifdef is necessary.
As I said, not necessary, but it might be the easiest or even the
cleanest here. Something for you and the maintainers to fight about,
I'll stay out of it :-)
> However, my question was related to another part of the current
> patchset, where the functions are always refined:
>
>
> On PPC32 we set:
>
> +#define SLICE_LOW_SHIFT 28
> +#define SLICE_HIGH_SHIFT 0
>
> On PPC64 we set:
>
> #define SLICE_LOW_SHIFT 28
> #define SLICE_HIGH_SHIFT 40
>
> We define:
>
> +#define slice_bitmap_zero(dst, nbits) \
> + do { if (nbits) bitmap_zero(dst, nbits); } while (0)
>
>
> We have a function with:
> {
> slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
> slice_bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
> }
SLICE_NUM_xx is not the same as SLICE_xx_SHIFT; I don't see how any of
those shift values give nbits == 0.
> So the question is to find the better approach. Is the above approach
> correct, including performance wise ?
If slice_bitmap_zero is inlined (or partially inlined) it is fine. Is it?
Segher
prev parent reply other threads:[~2018-01-23 21:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-17 9:22 [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32 Christophe Leroy
2018-01-17 9:22 ` [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address Christophe Leroy
2018-01-19 8:26 ` Aneesh Kumar K.V
2018-01-19 8:49 ` Christophe LEROY
2018-01-27 9:37 ` Michael Ellerman
2018-01-17 9:22 ` [PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices Christophe Leroy
2018-01-19 8:30 ` Aneesh Kumar K.V
2018-01-19 8:59 ` Christophe LEROY
2018-01-19 9:06 ` Aneesh Kumar K.V
2018-01-17 9:22 ` [PATCH v2 4/5] powerpc/8xx: Increase the number of mm slices Christophe Leroy
2018-01-17 9:22 ` [PATCH v2 5/5] powerpc/mm: Remove intermediate bitmap copy in 'slices' Christophe Leroy
2018-01-19 8:24 ` [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32 Aneesh Kumar K.V
2018-01-19 8:44 ` Christophe LEROY
2018-01-19 9:02 ` Aneesh Kumar K.V
2018-01-19 9:07 ` Christophe LEROY
2018-01-19 9:13 ` Aneesh Kumar K.V
2018-01-19 9:45 ` Christophe LEROY
2018-01-20 8:22 ` christophe leroy
2018-01-20 17:56 ` Segher Boessenkool
2018-01-22 7:52 ` Christophe LEROY
2018-01-23 21:47 ` Segher Boessenkool [this message]
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=20180123214659.GG21977@gate.crashing.org \
--to=segher@kernel.crashing.org \
--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.