All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralph Blach <rcblach@raleigh.ibm.com>
To: Dan Malek <dan@mvista.com>
Cc: frowand@mvista.com, linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: kernel mapping
Date: Tue, 16 Jan 2001 12:10:13 -0500	[thread overview]
Message-ID: <3A648075.5093ADAD@raleigh.ibm.com> (raw)
In-Reply-To: 3A647BC7.15F669F3@mvista.com

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Dan,

Thanks for the info.  I agree that Pinned tlbs could be maintence
headache with each 4xx/8xx
chip requiring a different set of pinned tlbs.

Chip

Dan Malek wrote:
>
> Ralph Blach wrote:
> >
> > Why do we need simulated bat registers.
>
> To improve performance.  Right now, on the 4xx there is the
> concept of "pinned" TLB entries to reduce/eliminate TLB misses
> on large mapped areas (like kernel text/data or I/O).  The 8xx
> does this in some custom applications as well.  These are just
> hacks that are headed down a disastrous maintenance path that
> need to be stopped now for a more generic solution.
>
> I have been experimenting with many different methods of using
> the "large" page table sizes through the generic memory management
> methods that already exist in the kernel.  I believe I can wrap
> the concept of the pinned TLB entries into the same logic as BAT
> register management on the bigger processors.  Hence, I call them
> simulated BAT registers....the semantics aren't quite the same.
>
> The BAT registers are a really good thing, and although the large
> page size TLB entries are more flexible, they require more software
> overhead.  I would like to make some generic Linux MM modifications
> to help us support variable page sizes, but I suspect that will
> never happen.
>
>         -- Dan
>

[-- Attachment #2: Card for Ralph Blach --]
[-- Type: text/x-vcard, Size: 247 bytes --]

begin:vcard
n:Blach;Ralph
tel;work:919-543-1207
x-mozilla-html:TRUE
url:www.ibm.com
org:IBM MicroElectronics
adr:;;3039 Cornwallis		;RTP;NC;27709;USA
version:2.1
email;internet:rcblach@raleigh.ibm.com
x-mozilla-cpt:;15936
fn:Ralph Blach
end:vcard

  reply	other threads:[~2001-01-16 17:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-15 23:13 kernel mapping Dan Malek
2001-01-16  3:07 ` Frank Rowand
2001-01-16  3:55   ` Dan Malek
2001-01-16 11:37   ` Ralph Blach
2001-01-16 16:50     ` Dan Malek
2001-01-16 17:10       ` Ralph Blach [this message]
2001-01-16 17:47       ` David Edelsohn
2001-01-16 21:57         ` Dan Malek
2001-01-17 10:51         ` Gabriel Paubert
2001-01-17 17:45           ` David Edelsohn
2001-01-16 19:56       ` Frank Rowand
2001-01-16 22:13         ` Dan Malek
2001-01-17  0:04           ` Frank Rowand
2001-01-17  7:02             ` Dan Malek

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=3A648075.5093ADAD@raleigh.ibm.com \
    --to=rcblach@raleigh.ibm.com \
    --cc=dan@mvista.com \
    --cc=frowand@mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.