From: Daniel Robbins <drobbins@gentoo.org>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: "David S. Miller" <davem@redhat.com>,
benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
andrea@suse.de, alan@redhat.com, Andrew Morton <akpm@zip.com.au>,
vherva@niksula.hut.fi, Linux Weekly News <lwn@lwn.net>,
paulus@samba.org
Subject: Re: Athlon/AGP issue update
Date: 23 Jan 2002 09:57:52 -0700 [thread overview]
Message-ID: <1011805072.10952.64.camel@inventor.gentoo.org> (raw)
In-Reply-To: <200201231631.g0NGVcS426406@saturn.cs.uml.edu>
In-Reply-To: <200201231631.g0NGVcS426406@saturn.cs.uml.edu>
On Wed, 2002-01-23 at 09:31, Albert D. Cahalan wrote:
> 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")
>
> BTW, I'd say the Athlon is pretty broken to set the dirty bit
> before a store is certain. The CPU has to be able to set this
> bit on a clean cache line anyway, so I don't see how this
> brokenness could help performance. Indeed, it hurts performance
> by causing erroneous memory bus traffic. (It's a bug.)
The answer I got from AMD on this is that because the page is marked as
cacheable, they are _allowed_ to do this. Cacheable means that you are
allowed to cache, and also means that you are allowed to write back into
main memory if a cache line is marked dirty. At least that's how they
explained it to me. I believe the way they explained it to me is that
due to the page being cacheable, the CPU "owns" the page.
I don't know if I'd describe the writing out to main memory as a bug as
much as it is an area where, for whatever reason, AMD decided not to add
some additional processor resources to handle this particular case.
Maybe the current behavior allowed them to implement speculative writes
much more efficiently (from a # of transistors on the chip perspective)
than if they added special logic so that these speculative writes were
*not* written out to main memory. To me, this particular bug seems more
like an unfortunate coincidence of having a non-cache-coherent GART
working alongside a cache-coherent CPU.
Well, at least you guys see how someone at NVIDIA could mistake this for
a CPU bug. If the kernel is affected, I hope we can find a nice
workable solution to this problem that doesn't involve disabling 4Mb
pages.
Also, everyone -- I can forward any additional questions you may have to
the people at AMD and get answers for you. All I ask is that these
questions come from actual people who will be looking into a solution,
since that is of course my main concern. I can then post answers from
AMD to this list for all to read.
Best Regards,
--
Daniel Robbins <drobbins@gentoo.org>
Chief Architect/President http://www.gentoo.org
Gentoo Technologies, Inc.
next prev parent reply other threads:[~2002-01-23 16:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200201231010.g0NAAuE05886@Port.imtp.ilyichevsk.odessa.ua>
2002-01-23 9:52 ` 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 [this message]
2002-01-23 17:14 ` benh
2002-01-23 23:14 ` Albert D. Cahalan
2002-01-25 18:17 ` Val Henson
2002-01-23 19:20 ` Oliver Neukum
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
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=1011805072.10952.64.camel@inventor.gentoo.org \
--to=drobbins@gentoo.org \
--cc=acahalan@cs.uml.edu \
--cc=akpm@zip.com.au \
--cc=alan@redhat.com \
--cc=andrea@suse.de \
--cc=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--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
all inboxes | Powered by JetHome®