From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: "Finney, Steve" <Steve.Finney@SpirentCom.COM>, linux-mips@linux-mips.org
Subject: Re: User-mode drivers and TLB
Date: Tue, 23 Sep 2003 23:47:53 -0700 [thread overview]
Message-ID: <20030924064753.GA8974@linux-mips.org> (raw)
In-Reply-To: <16240.12304.556561.464629@gladsmuir.mips.com>
On Tue, Sep 23, 2003 at 12:35:44PM +0100, Dominic Sweetman wrote:
> As usual, I guess the first thing is to try doing it the standard way
> and then try to measure how much time is being spent in extra TLB misses
> generated by your application. Some MIPS CPUs have "performance
> counters" which might be able to count TLB misses, but you'll more
> likely have to instrument the TLB miss code.
>
> If it does turn out that TLB replacement is a big drain:
>
> Most MIPS CPU hardware allows you to map large chunks of memory with a
> single TLB entry: often up to 16Mbytes at a time. But I don't know
> how you'd persuade Linux how to do that.
As an indication at how effective large pagesize support can be for
applications, take a look at the two USENIX 98 papers titled "General
Purpose Operating System Support for Multiple Page Sizes" by SGI about
IRIX and the "Implementation of Multiple Page Size support in HP-UX"
presented on the same. Given that we have what QED once called the
slowest TLB reload handler they've even seen the impact could be even
stronger than demonstrated in these two papers. The implementation
described has been condemened by Linus as stupid and unacceptable. I
expect a conceptually different optmization on MIPS late this year.
In any case the paper show how costly TLB exception handlers can be;
the reason why I yell at about everybody who's mentioning the phrase
"wired tlb entries".
For the time being Linux has large page support for the kernel - read
KSEG0 / KSEGX. Another optimization is also the use of the global bit
for all kernel mappings and for 2.6 support for hugetlbfs on MIPS should
also be fairly easy.
Btw, again and again the MIPS r4k-style TLBs are a bit of a pain because
each entry maps a pair of pages which share some of their attributes ...
Ralf
next prev parent reply other threads:[~2003-09-24 6:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-22 20:19 User-mode drivers and TLB Finney, Steve
2003-09-22 20:19 ` Finney, Steve
2003-09-23 11:35 ` Dominic Sweetman
2003-09-23 11:35 ` Dominic Sweetman
2003-09-24 6:47 ` Ralf Baechle [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-09-23 19:41 Finney, Steve
2003-09-23 19:41 ` Finney, Steve
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=20030924064753.GA8974@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=Steve.Finney@SpirentCom.COM \
--cc=dom@mips.com \
--cc=linux-mips@linux-mips.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