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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).