| 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 |
| Previous by Date: | Re: PATCH: Fix ll/sc for mips (take 3), Maciej W. Rozycki |
|---|---|
| Next by Date: | Re: PATCH: Fix ll/sc for mips (take 3), Maciej W. Rozycki |
| Previous by Thread: | Re: PATCH: Fix ll/sc for mips (take 3), Maciej W. Rozycki |
| Next by Thread: | Re: PATCH: Fix ll/sc for mips (take 3), Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |