From: <benh@kernel.crashing.org>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
"David S. Miller" <davem@redhat.com>
Cc: <drobbins@gentoo.org>, <linux-kernel@vger.kernel.org>,
<andrea@suse.de>, <alan@redhat.com>, <akpm@zip.com.au>,
<vherva@niksula.hut.fi>, <lwn@lwn.net>, <paulus@samba.org>
Subject: Re: Athlon/AGP issue update
Date: Wed, 23 Jan 2002 18:14:19 +0100 [thread overview]
Message-ID: <20020123171419.29358@mailhost.mipsys.com> (raw)
In-Reply-To: <200201231631.g0NGVcS426406@saturn.cs.uml.edu>
In-Reply-To: <200201231631.g0NGVcS426406@saturn.cs.uml.edu>
>AGP might be non-coherent. If so, then the CPU should use a
>non-coherent mapping to avoid useless memory bus traffic.
>User code has access to some cache control instructions,
>so one may mark the memory cacheable for better performance
>even when it is non-coherent. ("flush when you're done")
That's unfortunately not enough. The mapping of the page to
userland and the in-kernel mapping of the AGP aperture are done
with non-cacheable attribute. _BUT_, that same memory is also
mapped as part of the RAM linear mapping of the kernel (the
BAT mapping on PPC). The problem happens when some code working
near the end of a different page via this linear mapping cause
a speculative access to happen on the next page. This will have
the side-effect of loading the cache with a line from the page
used by AGP.
I think PPC does only speculative reads, but even those (non dirty
cache lines) may cause trouble in our case.
Now, we have to check if the PPC is allowed to do speculative
reads accross page boundaries. If it's the case, then we are screwed
and I will have to cleanup the code allowing the kernel to run without
the BAT mapping (with a performance impact unfortunately).
Ben.
next prev parent reply other threads:[~2002-01-23 17:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-23 9:52 Athlon/AGP issue update Daniel Robbins
2002-01-23 10:18 ` David S. Miller
2002-01-23 2:46 ` benh
2002-01-23 14:08 ` David S. Miller
2002-01-23 15:47 ` benh
2002-01-25 18:34 ` Val Henson
2002-01-26 0:20 ` Benjamin Herrenschmidt
2002-01-27 19:22 ` Val Henson
2002-01-27 19:32 ` Benjamin Herrenschmidt
2002-01-23 16:31 ` Albert D. Cahalan
2002-01-23 16:57 ` Daniel Robbins
2002-01-23 17:14 ` benh [this message]
2002-01-23 23:14 ` Albert D. Cahalan
2002-01-25 18:17 ` Val Henson
2002-01-23 19:20 ` Oliver Neukum
[not found] ` <200201231010.g0NAAuE05886@Port.imtp.ilyichevsk.odessa.ua>
2002-01-23 10:24 ` David S. Miller
2002-01-23 10:31 ` Rik van Riel
2002-01-23 11:39 ` David S. Miller
2002-01-23 11:39 ` William Lee Irwin III
2002-01-23 11:47 ` David S. Miller
2002-01-23 17:09 ` Albert D. Cahalan
2002-01-23 18:38 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2002-01-23 10:38 Studierende der Universitaet des Saarlandes
2002-01-23 11:44 ` David S. Miller
2002-01-23 12:32 ` Momchil Velikov
2002-01-23 12:34 ` David S. Miller
2002-01-23 12:41 ` Momchil Velikov
2002-01-23 14:50 ` Manfred Spraul
2002-01-23 11:44 ` David Woodhouse
2002-01-23 11:49 ` David S. Miller
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=20020123171419.29358@mailhost.mipsys.com \
--to=benh@kernel.crashing.org \
--cc=acahalan@cs.uml.edu \
--cc=akpm@zip.com.au \
--cc=alan@redhat.com \
--cc=andrea@suse.de \
--cc=davem@redhat.com \
--cc=drobbins@gentoo.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lwn@lwn.net \
--cc=paulus@samba.org \
--cc=vherva@niksula.hut.fi \
/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