linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tirumala Reddy Marri <tmarri@amcc.com>
Cc: Olof Johansson <olof@lixom.net>, linuxppc-dev@ozlabs.org
Subject: RE: Disabling L1 D-cache and side effects
Date: Wed, 01 Oct 2008 08:56:16 +1000	[thread overview]
Message-ID: <1222815376.9006.83.camel@pasglop> (raw)
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C060535A8@SDCEXCHANGE01.ad.amcc.com>

On Tue, 2008-09-30 at 15:26 -0700, Tirumala Reddy Marri wrote:
> Ben,
>     I got to bring up Linux on one of the 440 processors with out L1
> dcache to do some bench marking  and compare with  L1 d-cache enabled.  
> 
> I am avoiding any references to dcbz ,dcbt and dcbst .   Also the TLB's
> are created with cache inhibited. I looked at lwarx/stwcx description,
> there seem to be no dependency on L1 cache.

Ok. Well, they are generally implemented at the L2 level but maybe not
on 440, architecturally, they must be used on cacheable memory but it's
possible that 440 being not SMP coherent, the actual implementation of
those is too dumb to care.

> I don't see any critical exceptions or traps. All I  see is /init/bin
> failing to execute because data is corrupted. 

Have you properly replaced dcbz with multiple stores ? I did some bring
up work internally on some stuff where dcbz wasn't quite there yet and
one pitfall to be careful is that if you force-enable the alternate
CONFIG_8xx implementation in the various copy & memset routines in
arch/powerpc/lib, you also need to fix those implementations to copy
or clear 32 bytes instead of just 16, as 8xx has 16 byte cache lines.

Typically failing to do so causes things like memset to fail to properly
clear things such as page tables and thus random crap occurs.

Cheers,
Ben.

> Thanks,
> Marri

> 
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] 
> Sent: Tuesday, September 30, 2008 2:31 PM
> To: Tirumala Reddy Marri
> Cc: Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: RE: Disabling L1 D-cache and side effects
> 
> On Tue, 2008-09-30 at 09:57 -0700, Tirumala Reddy Marri wrote:
> > Ben,
> >   Thanks for the response. I am wondering how user space would get 
> > affected by absence of L1 Dcache.
> 
> You didn't answer my question :-)
> 
> Well, as I said, things like lwarx/stwcx not working, dcbz taking
> alignment exceptions, etc...
> 
> Ben.
> 
> > Thanks,
> > Marri
> > 
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Tuesday, September 30, 2008 12:16 AM
> > To: Tirumala Reddy Marri
> > Cc: Olof Johansson; linuxppc-dev@ozlabs.org
> > Subject: RE: Disabling L1 D-cache and side effects
> > 
> > On Mon, 2008-09-29 at 14:38 -0700, Tirumala Reddy Marri wrote:
> > > Could you please point me to the which does the Critical error 
> > > (Machine
> > > Check) recovery. BTW I am successful booting the Linux until rootfs 
> > > is
> > 
> > > being mounted. It fails to mount the Linux saying that blocks are 
> > > corrupted in file system. I had to modify lots of initial bring up 
> > > code to disable D-cache and make sure all TLB's are cache inhibited.
> > > Ando also made sure none of the misc_32.S , entry_32.S and head.S 
> > > makes any references to d-cache.
> > 
> > Why the heck are you doing that btw ? AFAIK, as Olof says, things like
> 
> > atomic operations will not work, dcbz neither etc... it's likely that 
> > even if you manage to plaster around all of this in the kernel, 
> > whatever userspace code you'll try to run in userspace will blow up
> too...
> > 
> > Cheers,
> > Ben.

  reply	other threads:[~2008-09-30 22:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9323BAFB78DE7C4183466AD03F73EA424D46071D@SDCEXCHANGE01.ad.amcc.com>
2008-09-29 17:05 ` Disabling L1 D-cache and side effects Tirumala Reddy Marri
2008-09-29 18:04   ` Olof Johansson
2008-09-29 21:00     ` Tirumala Reddy Marri
2008-09-29 21:14       ` Olof Johansson
2008-09-29 21:38         ` Tirumala Reddy Marri
2008-09-30  7:16           ` Benjamin Herrenschmidt
2008-09-30 16:57             ` Tirumala Reddy Marri
2008-09-30 21:30               ` Benjamin Herrenschmidt
2008-09-30 22:26                 ` Tirumala Reddy Marri
2008-09-30 22:56                   ` Benjamin Herrenschmidt [this message]
2008-10-01 18:07                     ` Tirumala Reddy Marri

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=1222815376.9006.83.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=olof@lixom.net \
    --cc=tmarri@amcc.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 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).