All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	bg-linux@lists.anl-external.org
Subject: Re: [PATCH 5/7] [RFC] force 32-byte aligned kmallocs
Date: Fri, 20 May 2011 11:50:03 +1000	[thread overview]
Message-ID: <1305856203.7481.116.camel@pasglop> (raw)
In-Reply-To: <BANLkTimc3jQTOJdqAiqbPxGQNVWe39VqfQ@mail.gmail.com>

On Thu, 2011-05-19 at 19:47 -0500, Eric Van Hensbergen wrote:
> On Thu, May 19, 2011 at 7:36 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2011-05-18 at 16:24 -0500, Eric Van Hensbergen wrote:
> >>
> >> -#ifdef CONFIG_NOT_COHERENT_CACHE
> >> +#if defined(CONFIG_NOT_COHERENT_CACHE) || defined(CONFIG_BGP)
> >>  #define ARCH_DMA_MINALIGN    L1_CACHE_BYTES
> >>  #endif
> >
> > Is DMA cache coherent on BG/P ? That's odd for a 4xx base :-)
> >
> 
> My understanding of things (which could be totally wrong) is that the
> DMA we care about on BG/P (namely the Torus and Collective networks)
> is coherent at the L2.  Of course the change in question is talking
> about L1_CACHE_BYTES, so my reading of this is that its a sleazy way
> of getting aligned mallocs that make interactions with the tightly
> coupled networks easier/more-efficient.  I'm open to alternative
> suggestions.

But if it's not coherent with L1, then you sould have
CONFIG_NOT_COHERENT_CACHE set and not need that patch... or am I missing
something ?

One thing we should do some day as well is make that whole non-coherent
be runtime selected, on the list of things to fix 440+47x in the same
kernel. Pfiew....

Cheers,
Ben.


WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	bg-linux@lists.anl-external.org
Subject: Re: [PATCH 5/7] [RFC] force 32-byte aligned kmallocs
Date: Fri, 20 May 2011 11:50:03 +1000	[thread overview]
Message-ID: <1305856203.7481.116.camel@pasglop> (raw)
In-Reply-To: <BANLkTimc3jQTOJdqAiqbPxGQNVWe39VqfQ@mail.gmail.com>

On Thu, 2011-05-19 at 19:47 -0500, Eric Van Hensbergen wrote:
> On Thu, May 19, 2011 at 7:36 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2011-05-18 at 16:24 -0500, Eric Van Hensbergen wrote:
> >>
> >> -#ifdef CONFIG_NOT_COHERENT_CACHE
> >> +#if defined(CONFIG_NOT_COHERENT_CACHE) || defined(CONFIG_BGP)
> >>  #define ARCH_DMA_MINALIGN    L1_CACHE_BYTES
> >>  #endif
> >
> > Is DMA cache coherent on BG/P ? That's odd for a 4xx base :-)
> >
> 
> My understanding of things (which could be totally wrong) is that the
> DMA we care about on BG/P (namely the Torus and Collective networks)
> is coherent at the L2.  Of course the change in question is talking
> about L1_CACHE_BYTES, so my reading of this is that its a sleazy way
> of getting aligned mallocs that make interactions with the tightly
> coupled networks easier/more-efficient.  I'm open to alternative
> suggestions.

But if it's not coherent with L1, then you sould have
CONFIG_NOT_COHERENT_CACHE set and not need that patch... or am I missing
something ?

One thing we should do some day as well is make that whole non-coherent
be runtime selected, on the list of things to fix 440+47x in the same
kernel. Pfiew....

Cheers,
Ben.

  reply	other threads:[~2011-05-20  1:50 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 21:24 [PATCH 1/7] [RFC] Mainline BG/P platform support Eric Van Hensbergen
2011-05-18 21:24 ` Eric Van Hensbergen
2011-05-18 21:24 ` [PATCH 2/7] [RFC] add bluegene entry to cputable Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-20  0:35   ` Benjamin Herrenschmidt
2011-05-20  0:35     ` Benjamin Herrenschmidt
2011-05-20  1:08     ` Eric Van Hensbergen
2011-05-20  1:08       ` Eric Van Hensbergen
2011-05-20  1:50       ` Benjamin Herrenschmidt
2011-05-20  1:50         ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 3/7] [RFC] add support for BlueGene/P FPU Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-19  5:58   ` Michael Neuling
2011-05-19  5:58     ` Michael Neuling
2011-05-19 13:53     ` Eric Van Hensbergen
2011-05-19 13:53       ` Eric Van Hensbergen
2011-05-19 15:22       ` [bg-linux] " Kazutomo Yoshii
2011-05-19 21:36       ` Michael Neuling
2011-05-19 21:36         ` Michael Neuling
2011-05-19 21:55         ` Eric Van Hensbergen
2011-05-19 21:55           ` Eric Van Hensbergen
2011-05-19 23:16           ` Michael Neuling
2011-05-19 23:16             ` Michael Neuling
2011-05-20  0:30             ` Eric Van Hensbergen
2011-05-20  0:30               ` Eric Van Hensbergen
2011-05-20  0:43               ` Michael Neuling
2011-05-20  0:43                 ` Michael Neuling
2011-05-20  0:53       ` Benjamin Herrenschmidt
2011-05-20  0:52     ` Benjamin Herrenschmidt
2011-05-20  0:52       ` Benjamin Herrenschmidt
2011-05-19 21:41   ` [PATCH 3/7] [RFC][V2] add support for BlueGene/P Double FPU Eric Van Hensbergen
2011-05-19 21:41     ` Eric Van Hensbergen
2011-05-18 21:24 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH mode for BG/P Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-19 10:43   ` Josh Boyer
2011-05-19 10:43     ` Josh Boyer
2011-05-19 12:53     ` Eric Van Hensbergen
2011-05-19 12:53       ` Eric Van Hensbergen
2011-05-19 21:42   ` [PATCH 4/7] [RFC][V2] enable BGP_L1_WRITETHROUGH " Eric Van Hensbergen
2011-05-19 21:42     ` Eric Van Hensbergen
2011-05-20  1:01   ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH " Benjamin Herrenschmidt
2011-05-20  1:01     ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 5/7] [RFC] force 32-byte aligned kmallocs Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-20  0:36   ` Benjamin Herrenschmidt
2011-05-20  0:36     ` Benjamin Herrenschmidt
2011-05-20  0:47     ` Eric Van Hensbergen
2011-05-20  0:47       ` Eric Van Hensbergen
2011-05-20  1:50       ` Benjamin Herrenschmidt [this message]
2011-05-20  1:50         ` Benjamin Herrenschmidt
2011-05-20  1:32     ` [bg-linux] " Kazutomo Yoshii
2011-05-20  2:08       ` Benjamin Herrenschmidt
2011-05-20  2:08         ` Benjamin Herrenschmidt
2011-05-20  2:13         ` Benjamin Herrenschmidt
2011-05-20  2:13           ` Benjamin Herrenschmidt
2011-05-20  3:02           ` Kazutomo Yoshii
2011-05-20  3:13             ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 6/7] [RFC] enable early TLBs for BG/P Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-20  0:39   ` Benjamin Herrenschmidt
2011-05-20  0:39     ` Benjamin Herrenschmidt
2011-05-20  1:21     ` Eric Van Hensbergen
2011-05-20  1:21       ` Eric Van Hensbergen
2011-05-20  1:54       ` Benjamin Herrenschmidt
2011-05-20  1:54         ` Benjamin Herrenschmidt
2011-05-20  3:38         ` [bg-linux] " Kazutomo Yoshii
2011-05-20  3:38           ` Kazutomo Yoshii
2011-05-20  3:52           ` Benjamin Herrenschmidt
2011-05-20  3:52             ` Benjamin Herrenschmidt
2011-05-20 13:01             ` Eric Van Hensbergen
2011-05-20 22:20               ` Benjamin Herrenschmidt
2011-05-18 21:24 ` [PATCH 7/7] [RFC] SMP support code Eric Van Hensbergen
2011-05-18 21:24   ` Eric Van Hensbergen
2011-05-20  1:05   ` Benjamin Herrenschmidt
2011-05-20  1:05     ` Benjamin Herrenschmidt
2011-05-19 11:01 ` [PATCH 1/7] [RFC] Mainline BG/P platform support Josh Boyer
2011-05-19 11:01   ` Josh Boyer
2011-05-19 12:35   ` Eric Van Hensbergen
2011-05-19 12:35     ` Eric Van Hensbergen

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=1305856203.7481.116.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=bg-linux@lists.anl-external.org \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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.