From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
Geert Uytterhoeven <geert@linux-m68k.org>,
James Simmons <jsimmons@linux-fbdev.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
Date: Fri, 6 Apr 2001 14:09:20 +0400 [thread overview]
Message-ID: <20010406140920.A4866@jurassic.park.msu.ru> (raw)
In-Reply-To: <Pine.GSO.3.96.1010405150444.21134E-100000@delta.ds2.pg.gda.pl> <m17l0zw6mx.fsf@frodo.biederman.org>
In-Reply-To: <m17l0zw6mx.fsf@frodo.biederman.org>; from ebiederm@xmission.com on Thu, Apr 05, 2001 at 12:20:22PM -0600
On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached. You cannot do write-combing for video card
> memory.
Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
4x64 on ev6, IIRC. So alphas do write up to 32 or 64 bytes
in a single pci transaction.
> Memory barriers are a separate issue. On the alpha the
> natural way to implement it would be in the page table fill code.
> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.
You don't need memory barrier for that. "Write memory barriers" are
used to ensure correct write order, and "memory barriers" are used
to ensure that all pending reads/writes will complete before next read
or write.
Ivan.
next prev parent reply other threads:[~2001-04-06 10:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-05 3:04 James Simmons
2001-04-05 12:03 ` Eric W. Biederman
2001-04-05 12:12 ` Geert Uytterhoeven
2001-04-05 13:15 ` Maciej W. Rozycki
2001-04-05 18:20 ` Eric W. Biederman
2001-04-06 10:09 ` Ivan Kokshaysky [this message]
2001-04-06 13:19 ` Eric W. Biederman
2001-04-06 17:27 ` Maciej W. Rozycki
2001-04-06 18:34 ` Andrea Arcangeli
2001-04-06 19:31 ` Maciej W. Rozycki
2001-04-06 17:13 ` Maciej W. Rozycki
2001-04-08 18:11 ` Ivan Kokshaysky
2001-04-09 10:02 ` Maciej W. Rozycki
2001-04-09 11:05 ` Ivan Kokshaysky
2001-04-06 17:07 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2001-04-03 2:04 James Simmons
2001-04-01 14:54 James Simmons
2001-04-01 21:35 ` Jamie Lokier
2001-03-31 4:15 James Simmons
2001-03-31 4:11 James Simmons
2001-04-02 22:44 ` Alan Cox
2001-04-03 6:23 ` Geert Uytterhoeven
2001-04-03 12:21 ` Alan Cox
2001-04-04 7:50 ` Eric W. Biederman
2001-04-04 8:47 ` Jamie Lokier
2001-03-31 3:47 James Simmons
2001-03-31 14:15 ` Jamie Lokier
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=20010406140920.A4866@jurassic.park.msu.ru \
--to=ink@jurassic.park.msu.ru \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=geert@linux-m68k.org \
--cc=jsimmons@linux-fbdev.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@ds2.pg.gda.pl \
/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®