linux-mips
[Top] [All Lists]

Re: PATCH: Fix ll/sc for mips (take 3)

To: Hartvig Ekner <hartvige@mips.com>
Subject: Re: PATCH: Fix ll/sc for mips (take 3)
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Tue, 5 Feb 2002 13:12:57 +0100
Cc: Justin Carlson <justinca@ri.cmu.edu>, Daniel Jacobowitz <dan@debian.org>, "H . J . Lu" <hjl@lucon.org>, Dominic Sweetman <dom@algor.co.uk>, GNU C Library <libc-alpha@sources.redhat.com>, linux-mips@oss.sgi.com
In-reply-to: <200202050839.JAA00051@copsun18.mips.com>; from hartvige@mips.com on Tue, Feb 05, 2002 at 09:39:27AM +0100
References: <1012887022.3343.9.camel@xyzzy.stargate.net> <200202050839.JAA00051@copsun18.mips.com>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Tue, Feb 05, 2002 at 09:39:27AM +0100, Hartvig Ekner wrote:

> Note that the issue of a "LL" will trigger bus watching activity in the
> system logic (and maybe delays?) I would personally try to avoid issuing
> "dangling" ll's in the normal case, even though the functionality would
> be ok, and in some cases they are inavoidable.

Some of the processor manuals explicitly note that the execution of a
ll instruction may not be visible at all externally.  That's the case if
the address is already in a primary cache line in exclusive (ll) or
dirty (sc) state.  That makes even if a processor supports full coherency
since there is no reason to indicate the update to any other external
agent.  Or am I missing something?

  Ralf

<Prev in Thread] Current Thread [Next in Thread>