Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Gilad" <giladb@riverhead.com>, <linux-mips@linux-mips.org>
Subject: Re: Prefetches in memcpy
Date: Sun, 8 Dec 2002 11:01:43 +0100	[thread overview]
Message-ID: <006d01c29ea0$d0d15190$10eca8c0@grendel> (raw)
In-Reply-To: ECEPLLMMNGHMFBLHCLMACEALDGAA.giladb@riverhead.com

> As someone rather new to this list, and to mips-linux in general,
> can someone explain the problem, as well as how one can avoid 
> it or limit it's effects to a minimum ?

The problem is that memcpy() uses prefetch to pre-load the
cache from the copy source, but does so very naively, such
that it continues prefetching beyond the end of the block to
be copied.  This is a Bad Idea for a couple of reasons.
The first to be commented upon was the fact that it can
result in bus hangs/bus errors if the kernel is trying to copy
from the last few hundred bytes of physical memory, but 
the really nasty one is that it screws up cache coherence
for DMA I/O.

The no-brainer solution which has been proposed as a
stopgap is simply to stop doing prefetch in memcpy()
altogether.  The "correct" solution would be to have a
slightly more complex memcpy() loop which only does
prefetch up to the end of the source block, which is
what is now done in the x86 port.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Gilad <giladb@riverhead.com>, linux-mips@linux-mips.org
Subject: Re: Prefetches in memcpy
Date: Sun, 8 Dec 2002 11:01:43 +0100	[thread overview]
Message-ID: <006d01c29ea0$d0d15190$10eca8c0@grendel> (raw)
Message-ID: <20021208100143.fU3Vl_SdTJefj92Q-maEGPf3JkBRjSaG25gu35vqxM8@z> (raw)
In-Reply-To: ECEPLLMMNGHMFBLHCLMACEALDGAA.giladb@riverhead.com

> As someone rather new to this list, and to mips-linux in general,
> can someone explain the problem, as well as how one can avoid 
> it or limit it's effects to a minimum ?

The problem is that memcpy() uses prefetch to pre-load the
cache from the copy source, but does so very naively, such
that it continues prefetching beyond the end of the block to
be copied.  This is a Bad Idea for a couple of reasons.
The first to be commented upon was the fact that it can
result in bus hangs/bus errors if the kernel is trying to copy
from the last few hundred bytes of physical memory, but 
the really nasty one is that it screws up cache coherence
for DMA I/O.

The no-brainer solution which has been proposed as a
stopgap is simply to stop doing prefetch in memcpy()
altogether.  The "correct" solution would be to have a
slightly more complex memcpy() loop which only does
prefetch up to the end of the source block, which is
what is now done in the x86 port.

  reply	other threads:[~2002-12-08 10:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-05 13:45 Prefetches in memcpy Carsten Langgaard
2002-11-05 15:38 ` Ralf Baechle
2002-11-05 16:13   ` Kevin D. Kissell
2002-11-05 16:13     ` Kevin D. Kissell
2002-11-05 16:29     ` Ralf Baechle
2002-11-05 16:41     ` Ralf Baechle
2002-11-05 17:26     ` Alan Cox
2002-12-04 15:06   ` Carsten Langgaard
2002-12-05  9:32     ` Dominic Sweetman
2002-12-05 15:14       ` Carsten Langgaard
2002-12-05 15:47         ` Maciej W. Rozycki
2002-12-08  7:06     ` Gilad
2002-12-08 10:01       ` Kevin D. Kissell [this message]
2002-12-08 10:01         ` Kevin D. Kissell

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='006d01c29ea0$d0d15190$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=giladb@riverhead.com \
    --cc=linux-mips@linux-mips.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox