All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frank_rowand@mvista.com>
To: Gabriel Paubert <paubert@iram.es>
Cc: Brian Kuschak <brian.kuschak@skystream.com>,
	"'Dan Malek'" <dan@mvista.com>, Eli Chen <eli@routefree.com>,
	linuxppc-embedded@lists.linuxppc.org
Subject: Re: dcache BUG()
Date: Thu, 10 May 2001 11:39:17 -0700	[thread overview]
Message-ID: <3AFAE055.3396344C@mvista.com> (raw)
In-Reply-To: Pine.HPX.4.10.10105092010530.29518-100000@gra-ux1.iram.es


Gabriel Paubert wrote:
>
> On Wed, 9 May 2001, Brian Kuschak wrote:


> >
> > static __inline__ void atomic_set(atomic_t *v, int a)
> > {
> > c004f9e8:       38 00 00 01     li      r0,1
> >         int t;
> >
> >         __asm__ __volatile__("\n\
> > c004f9ec:       7d 60 f8 28     lwarx   r11,r0,r31
> > c004f9f0:       60 0b 00 00     ori     r11,r0,0
> > c004f9f4:       7d 60 f9 2d     stwcx.  r11,r0,r31
> > c004f9f8:       40 a2 ff f4     bne-    c004f9ec <d_alloc+0x90>
> >
> >         atomic_set(&dentry->d_count, 1);
>
> Is there any reason for atomic_set to use this sequence. I believe that a
> simple store (stw in this case) would be ok. This looks like a very
> convoluted and bloated way to set a variable. An aligned stw is guaranteed
> to set the variable atomically wrt all other processors.

Sorry I wasn't around for the beginning of this discussion (I was off with
visiting family...), but I'll jump in now.

I put this version of atomic_set() into Brian's source.  It is one of the
things that helped reduce the severity of the dcache symptoms.  You can't
just use a stw in atomic_set(), because the other atomic operations depend
upon the stwcx.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-05-10 18:39 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-09 16:40 dcache BUG() Brian Kuschak
2001-05-09 18:31 ` Dan Malek
2001-05-09 19:18 ` Gabriel Paubert
2001-05-10 18:39   ` Frank Rowand [this message]
2001-05-10 18:49     ` Gabriel Paubert
2001-05-10 19:10       ` Frank Rowand
2001-05-11  4:23         ` Paul Mielke
2001-05-11 10:09         ` Gabriel Paubert
2001-05-10 20:56       ` Dan Malek
2001-05-10 23:14         ` Cort Dougan
2001-05-11 11:01           ` Gabriel Paubert
2001-05-11 10:57         ` Gabriel Paubert
2001-05-11 18:49           ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2001-05-12  0:44 Brian Kuschak
2001-05-12  0:57 ` Eli Chen
2001-05-14  9:28   ` Gabriel Paubert
2001-05-10 21:20 Brian Kuschak
2001-05-10 21:26 ` Dan Malek
2001-05-08 17:43 Brian Kuschak
2001-05-09 11:06 ` Gabriel Paubert
2001-05-08 15:43 Brian Kuschak
2001-05-08  3:36 Brian Kuschak
2001-05-08  1:53 Brian Kuschak
2001-05-08  2:03 ` Dan Malek
2001-05-08 11:59 ` Gabriel Paubert
2001-05-08  0:40 Brian Kuschak
2001-05-07 23:01 Brian Kuschak
2001-05-07 22:19 Brian Kuschak
2001-05-07 22:35 ` Cort Dougan
2001-05-07 22:43 ` Eli Chen
2001-05-07 19:04 Eli Chen
2001-05-07 21:04 ` Dan Malek
2001-05-07 21:17 ` Dan Malek
2001-05-07 21:30   ` Tom Rini
2001-05-07 23:03     ` Dan Malek
2001-05-07 21:47   ` Eli Chen
2001-05-07 23:01     ` Dan Malek
2001-05-07 23:06     ` Gabriel Paubert
2001-05-07 23:15       ` Dan Malek
2001-05-07 23:28         ` Gabriel Paubert
2001-05-07 23:35         ` Eli Chen
2001-05-07 23:36           ` Dan Malek
2001-05-08  0:16             ` Eli Chen
2001-05-08  0:41               ` Dan Malek
2001-05-08  1:14                 ` Eli Chen
2001-05-08  1:11                   ` Dan Malek
2001-05-08 18:01                     ` David Blythe
2001-05-08 20:27                       ` Dan Malek
2001-05-08 21:34                         ` David Blythe
2001-05-08 21:49                           ` Dan Malek
2001-05-08 22:34                             ` Ira Weiny
2001-05-08 22:53                               ` Dan Malek
2001-05-08  1:37             ` Gabriel Paubert
2001-05-08  1:44               ` Dan Malek
2001-05-07 23:40           ` Gabriel Paubert
2001-05-07 17:21 Brian Kuschak
2001-05-07 20:58 ` Dan Malek

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=3AFAE055.3396344C@mvista.com \
    --to=frank_rowand@mvista.com \
    --cc=brian.kuschak@skystream.com \
    --cc=dan@mvista.com \
    --cc=eli@routefree.com \
    --cc=frowand@mvista.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=paubert@iram.es \
    /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.