From: christophe leroy <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Kyle Moffett <Kyle.D.Moffett@boeing.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/4] Partially revert "powerpc: Remove duplicate cacheable_memcpy/memzero functions"
Date: Fri, 15 May 2015 19:58:27 +0200 [thread overview]
Message-ID: <555633C3.9000308@c-s.fr> (raw)
In-Reply-To: <1431564565.3868.157.camel@freescale.com>
Le 14/05/2015 02:49, Scott Wood a écrit :
> On Tue, 2015-05-12 at 15:32 +0200, Christophe Leroy wrote:
>> This partially reverts
>> commit 'powerpc: Remove duplicate cacheable_memcpy/memzero functions
>> ("f909a35bdfb7cb350d078a2cf888162eeb20381c")'
> I don't have that SHA. Do you mean
> b05ae4ee602b7dc90771408ccf0972e1b3801a35?
Right, took it from the wrong tree sorry.
>
>> Functions cacheable_memcpy/memzero are more efficient than
>> memcpy/memset as they use the dcbz instruction which avoids refill
>> of the cacheline with the data that we will overwrite.
> I don't see anything in this patchset that addresses the "NOTE: The old
> routines are just flat buggy on kernels that support hardware with
> different cacheline sizes" comment.
I believe the NOTE means that if a kernel is compiled for several CPUs
having different cache line size,
then it will not work. But it is also the case of other functions using
dcbz instruction, like copy_page() clear_page() copy_tofrom_user().
And indeed, this seems only possible in three cases:
1/ With CONFIG_44x as 47x has different size than 44x and 46x. However
it is explicitly stated in arch/powerpc/platforms/44x/Kconfig : "config
PPC_47x This option enables support for the 47x family of processors and
is not currently compatible with other 44x or 46x varients"
2/ With CONFIG_PPC_85xx, as PPC_E500MC has different size than other
E500. However it is explicitly stated in
arch/powerpc/platforms/Kconfig.cputype : "config PPC_E500MC This must be
enabled for running on e500mc (and derivatives such as e5500/e6500), and
must be disabled for running on e500v1 or e500v2."
3/ With CONFIG_403GCX as 403GCX has different size than other 40x.
However it seems to be no way to select CONFIG_403GCX from
arch/powerpc/platforms/40x/Kconfig
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
WARNING: multiple messages have this Message-ID (diff)
From: christophe leroy <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Joakim Tjernlund <joakim.tjernlund@transmode.se>,
Kyle Moffett <Kyle.D.Moffett@boeing.com>
Subject: Re: [PATCH 1/4] Partially revert "powerpc: Remove duplicate cacheable_memcpy/memzero functions"
Date: Fri, 15 May 2015 19:58:27 +0200 [thread overview]
Message-ID: <555633C3.9000308@c-s.fr> (raw)
In-Reply-To: <1431564565.3868.157.camel@freescale.com>
Le 14/05/2015 02:49, Scott Wood a écrit :
> On Tue, 2015-05-12 at 15:32 +0200, Christophe Leroy wrote:
>> This partially reverts
>> commit 'powerpc: Remove duplicate cacheable_memcpy/memzero functions
>> ("f909a35bdfb7cb350d078a2cf888162eeb20381c")'
> I don't have that SHA. Do you mean
> b05ae4ee602b7dc90771408ccf0972e1b3801a35?
Right, took it from the wrong tree sorry.
>
>> Functions cacheable_memcpy/memzero are more efficient than
>> memcpy/memset as they use the dcbz instruction which avoids refill
>> of the cacheline with the data that we will overwrite.
> I don't see anything in this patchset that addresses the "NOTE: The old
> routines are just flat buggy on kernels that support hardware with
> different cacheline sizes" comment.
I believe the NOTE means that if a kernel is compiled for several CPUs
having different cache line size,
then it will not work. But it is also the case of other functions using
dcbz instruction, like copy_page() clear_page() copy_tofrom_user().
And indeed, this seems only possible in three cases:
1/ With CONFIG_44x as 47x has different size than 44x and 46x. However
it is explicitly stated in arch/powerpc/platforms/44x/Kconfig : "config
PPC_47x This option enables support for the 47x family of processors and
is not currently compatible with other 44x or 46x varients"
2/ With CONFIG_PPC_85xx, as PPC_E500MC has different size than other
E500. However it is explicitly stated in
arch/powerpc/platforms/Kconfig.cputype : "config PPC_E500MC This must be
enabled for running on e500mc (and derivatives such as e5500/e6500), and
must be disabled for running on e500v1 or e500v2."
3/ With CONFIG_403GCX as 403GCX has different size than other 40x.
However it seems to be no way to select CONFIG_403GCX from
arch/powerpc/platforms/40x/Kconfig
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
next prev parent reply other threads:[~2015-05-15 17:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 13:32 [PATCH 0/4] powerpc32: use cacheable alternatives of memcpy and memset Christophe Leroy
2015-05-12 13:32 ` Christophe Leroy
2015-05-12 13:32 ` [PATCH 1/4] Partially revert "powerpc: Remove duplicate cacheable_memcpy/memzero functions" Christophe Leroy
2015-05-12 13:32 ` Christophe Leroy
2015-05-14 0:49 ` Scott Wood
2015-05-14 0:49 ` Scott Wood
2015-05-15 17:58 ` christophe leroy [this message]
2015-05-15 17:58 ` christophe leroy
2015-05-12 13:32 ` [PATCH 2/4] powerpc32: swap r4 and r5 in cacheable_memzero Christophe Leroy
2015-05-12 13:32 ` Christophe Leroy
2015-05-12 13:32 ` [PATCH 3/4] powerpc32: memset(0): use cacheable_memzero Christophe Leroy
2015-05-12 13:32 ` Christophe Leroy
2015-05-14 0:55 ` Scott Wood
2015-05-14 0:55 ` Scott Wood
2015-05-14 8:50 ` christophe leroy
2015-05-14 8:50 ` christophe leroy
2015-05-14 20:18 ` Scott Wood
2015-05-14 20:18 ` Scott Wood
2015-05-12 13:32 ` [PATCH 4/4] powerpc32: memcpy: use cacheable_memcpy Christophe Leroy
2015-05-12 13:32 ` 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=555633C3.9000308@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=Kyle.D.Moffett@boeing.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/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.