From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Val Henson <val@nmt.edu>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Athlon/AGP issue update
Date: Sat, 26 Jan 2002 01:20:45 +0100 [thread overview]
Message-ID: <20020126002045.17802@smtp.wanadoo.fr> (raw)
In-Reply-To: <20020125113443.C26874@boardwalk>
In-Reply-To: <20020125113443.C26874@boardwalk>
>On Wed, Jan 23, 2002 at 04:47:37PM +0100, benh@kernel.crashing.org wrote:
>> >I don't think your PPC case needs the kernel mappings messed with.
>> >I really doubt the PPC will speculatively fetch/store to a TLB
>> >missing address.... unless you guys have large TLB mappings on
>> >PPC too?
>>
>> Yes, we use BATs (sort of built-in fixed large TLBs) to map
>> the lowmem (or entire RAM without CONFIG_HIGHMEM).
>
>Looking at bat_mapin_ram, it looks like we only map the first 512MB of
>RAM with BATs, so we actually map the 512MB - 768MB range with PTEs
>(and highmem starts at 768MB). Two of the DBATs are used by I/O
>mappings, so that only leaves two DBATs of 256MB each to map lowmem
>anyway. Am I missing something?
No, except maybe my last patch that actually limits lowmem to 512Mb ;)
I don't think we use the io mapping BATs any more, do we ? (well,
maybe on PReP...) I don't on pmac.
>By the way, does the "nobats" option currently work on PowerMac?
No, nor on any other BAT-capable PPC (and that's the reason why I
did the above). Basically, our exception return path and some of
the hash manipulation functions aren't safe without BAT mapping,
especially on SMP when you can get evicted from the hash table
by the other CPU in places where taking hash faults isn't safe.
Ben.
next prev parent reply other threads:[~2002-01-26 0:53 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 [this message]
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
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=20020126002045.17802@smtp.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=val@nmt.edu \
/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