This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Fix ll/sc for mips (take 3)
- From: Ralf Baechle <ralf at oss dot sgi dot com>
- To: Hartvig Ekner <hartvige at mips dot com>
- Cc: Justin Carlson <justinca at ri dot cmu dot edu>, Daniel Jacobowitz <dan at debian dot org>, "H . J . Lu" <hjl at lucon dot org>, Dominic Sweetman <dom at algor dot co dot uk>, GNU C Library <libc-alpha at sources dot redhat dot com>, linux-mips at oss dot sgi dot com
- Date: Tue, 5 Feb 2002 13:12:57 +0100
- Subject: Re: PATCH: Fix ll/sc for mips (take 3)
- References: <firstname.lastname@example.org> <200202050839.JAA00051@copsun18.mips.com>
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?