| To: | "Kevin D. Kissell" <kevink@mips.com> |
|---|---|
| Subject: | Re: Promblem with PREF (prefetching) in memcpy |
| From: | Alan Cox <alan@lxorguk.ukuu.org.uk> |
| Date: | 04 Oct 2002 15:54:42 +0100 |
| Cc: | linux-mips@linux-mips.org |
| In-reply-to: | <016201c26bb0$b8609a30$10eca8c0@grendel> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <3D9D484B.4C149BD8@mips.com><200210041153.MAA12052@mudchute.algor.co.uk><3D9 D855B.12128FA2@mips.com><1033734968.31839.5.camel@irongate.swansea.linux .org.uk> <00fe01c26ba6$04943480$10eca8c0@grendel><1033737330.31861.30.camel@irongate. swansea.linux.org.uk> <010e01c26ba8$2c9400d0$10eca8c0@grendel> <1033739046.31861.35.camel@irongate.swansea.linux.org.uk> <016201c26bb0$b8609a30$10eca8c0@grendel> |
| Sender: | linux-mips-bounce@linux-mips.org |
On Fri, 2002-10-04 at 15:17, Kevin D. Kissell wrote: > Which is safe, simple, and efficient, but does seem to have the property > that there's a "cursed" page in the system that can be randomly allocated > and which will be curiously slow on memcopy(). That might or might not > be a problem in the embedded application space. Im curious why you think that. Its the same speed for all pages and all copies. If anything it is more efficient because we don't drag 320 bytes of crap across the bus that we dont actually want anyway. |
| Previous by Date: | Re: Promblem with PREF (prefetching) in memcpy, Dominic Sweetman |
|---|---|
| Next by Date: | do_ri and EPC adjustment, Kip Walker |
| Previous by Thread: | Re: Promblem with PREF (prefetching) in memcpy, Kevin D. Kissell |
| Next by Thread: | Re: Promblem with PREF (prefetching) in memcpy, Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |