From: ebiederm@xmission.com (Eric W. Biederman)
To: James Simmons <jsimmons@linux-fbdev.org>
Cc: 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: 05 Apr 2001 06:03:01 -0600 [thread overview]
Message-ID: <m1bsqbwo3u.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.31.0104041956240.1580-100000@linux.local>
In-Reply-To: James Simmons's message of "Wed, 4 Apr 2001 20:04:04 -0700 (PDT)"
James Simmons <jsimmons@linux-fbdev.org> writes:
> >>> As long as you are copying in real memory. So the PCI bus or the host
> bridge
> >>> implementation may be the actual limit.
> >>
> >> The CyrixIII sits on the same host bridges as the intel processors
> >
> >I don't know if it applies to this case but one thing I have seen make
> >a noticeable difference is whether or not write-combining is enabled.
> >If we have only be enabling MTRR's for intel this could do account
> >for it.
>
> I think what Geert was trying to point out is does MTRR perform was well
> with normal memory over bus to video memory transfers as compared to
> normal memory to normal memory transfers. MTTRs might not be optimzed for
> these kinds of transfers. I honestly can't say since I haven't tried it. I
> brought the MMX book home from works so I'm going to be experimenting
> with it this weekend to find out. I really like to compare the MMX
> performance to the word aligned transfers over the bus I have going. I had
> a bug in my soft accel code that prevented word alignment. Once I fixed
> that bug I seen a 10 fold improvement in rendering on the framebuffer.
> I'm not kidding about that improvement either :-)
>
> MTTRs enabled always makes a difference. I liek to try it with and
> without. I will do some benchmarkings.
While I'm thinking about it what we really should be using is the PAT
extension and not MTRR's. The PAT extension allows you to set the
attributes per page so you don't have the resource contention you do
with MTRR's. I can just imagine the performance challenges right now
if you try to do a multi-head where multi > number of free MTRR's.
What happens with write-combining is active is that close adjacent
writes are batched together. Without write-combining you tend to get
32bit writes on a bus with a word size of 64 or more bits. By the way
does anyone know who didn't implement MTRR's or the equivalent on
alpha so we can shoot them?
Eric
next prev parent reply other threads:[~2001-04-05 12:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-05 3:04 [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?] James Simmons
2001-04-05 12:03 ` Eric W. Biederman [this message]
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
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=m1bsqbwo3u.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jsimmons@linux-fbdev.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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