mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: davidm@hpl.hp.com, Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org, davidm@napali.hpl.hp.com
Subject: Re: adjust prefetch in free_one_pgd()
Date: Fri, 2 Aug 2002 08:39:24 -0700	[thread overview]
Message-ID: <15690.42924.410428.28956@napali.hpl.hp.com> (raw)
In-Reply-To: <1028293461.18309.53.camel@irongate.swansea.linux.org.uk>

>>>>> On 02 Aug 2002 14:04:21 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> said:

  Alan> It isnt a case of PREFETCH_STRIDE - thats the optimal
  Alan> fetchahead. You must never prefetch an address beyond the end
  Alan> of an object. So you actually need two loops one prefetching,
  Alan> then one to finish the job off which does not prefetch.

  Alan> Otherwise one day your page ends up against the ISA or PCI
  Alan> address space or something else undesirable and on some cpus
  Alan> the prefetch then variously confuses the PCI device or
  Alan> corrupts the cache.

I thought the prefetches API intended this to be a safe operation?
It's definitely not an issue on ia64: there, prefetches against
uncached memory translations are automatically canceled.

Note that there are many other prefetches in the kernel which may end
up prefetch "invalid" addresses (though it may often be address 0
that's being prefetched; perhaps that OK even on arches where you may
not prefetch against ISA or PCI addresses).

  Alan> Prefetching stuff you don't need is bad manners anyway 8)

That would work for me (though it would increase code size).  My patch
was intended as a minimal fix for a rather obvious typo (or perhaps it
was a thinko... ;-).

	--david

  reply	other threads:[~2002-08-02 15:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-02  0:12 David Mosberger
2002-08-02 13:04 ` Alan Cox
2002-08-02 15:39   ` David Mosberger [this message]
2002-08-02 15:46     ` Linus Torvalds
2002-08-02 15:56       ` Dave Jones
2002-08-02 15:59         ` Linus Torvalds
2002-08-02 16:04           ` Dave Jones
2002-08-02 17:49       ` Alan Cox
2002-08-02 16:38         ` David Mosberger
2002-08-02 17:58           ` Alan Cox
2002-08-02 16:53             ` David Mosberger
2002-08-03 16:59       ` David Woodhouse
2002-08-03 17:22         ` Linus Torvalds
2002-08-03 17:39           ` David Woodhouse
2002-08-03 19:36             ` Linus Torvalds
2002-08-03 22:03               ` David Woodhouse
2002-08-03 22:40                 ` Linus Torvalds

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=15690.42924.410428.28956@napali.hpl.hp.com \
    --to=davidm@napali.hpl.hp.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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

all inboxes | Powered by JetHome®