Subject: TLB entries > 4kb

From: [email-masked]
Date: Thu, 12 Feb 1998 05:56:48 +0100

Some architectures can use multiple page sizes in the TLB at the same time.
This would for example allow to map memory allocations > PAGE_SIZE using just
a single TLB entry if the circumstances are just right, thereby
reducing / eleminating TLB trashing.  This should improve the performance
for huge apps quite a bit.  Some architectures could partially get rid of
the sick effects of their virtual indexed primary caches as well.  All that
is needed for this to work is to have sufficiently large physical pages with
sufficient alignment at hand.

Has anybody ever looked into implementing that?  What architectures besides
MIPS could take advantage of such a feature?

  Ralf

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 11 Feb 1998 21:50:12 -0800

From: [email-masked]
   Date: Thu, 12 Feb 1998 05:56:48 +0100

   Has anybody ever looked into implementing that?  What architectures
   besides MIPS could take advantage of such a feature?

We already use it on Sparc64 for mmap()'ing the frame buffers, we
could easily extend it to work for mmap()'s of real memory.  Check out
arch/sparc64/mm/generic.c in the vger CVS tree for details.

Later,
David S. Miller
[email-masked]

---

From: [email-masked] (Alan Cox)
Date: Thu, 12 Feb 1998 08:51:00 +0000 (GMT)

> MIPS could take advantage of such a feature?

On the intel its a huge win to map PCI frame buffers using 4Mbyte pages, but
the kernel mmap really can't hack the idea right now. A pity cos if you
hack it in and make sure you never unmap it you get 2-3% better X performance

---

From: Michael Lausch <[email-masked]>
Date: Thu, 12 Feb 1998 13:10:02 +0100

>>>>> "r" == ralf  <[email-masked]>
>>>>> wrote the following on Thu, 12 Feb 1998 05:56:48 +0100

r> Some architectures can use multiple page sizes in the TLB at the same time.
r> This would for example allow to map memory allocations > PAGE_SIZE using just
r> a single TLB entry if the circumstances are just right, thereby
r> reducing / eleminating TLB trashing.  This should improve the performance
r> for huge apps quite a bit.  Some architectures could partially get rid of
r> the sick effects of their virtual indexed primary caches as well.  All that
r> is needed for this to work is to have sufficiently large physical pages with
r> sufficient alignment at hand.

r> Has anybody ever looked into implementing that?  What architectures besides
r> MIPS could take advantage of such a feature?

The MPC860. We now have 8 MByte Page Table entries for the Kernel Address
Space and the Dual Ported RAM used to communicate with the CPM.

r>   Ralf

r> -
r> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
r> the body of a message to [email-masked]

---

From: MOLNAR Ingo <[email-masked]>
Date: Thu, 12 Feb 1998 19:00:41 +0100 (CET)

> hack it in and make sure you never unmap it you get 2-3% better X performance

i tried to hack this half a year ago, but had to find out that 4MB pages
are only valid for kernel mappings, which means we'd have to make X a ring
0 process too ...

-- mingo

---

From: "J.D. Bakker" <[email-masked]>
Date: Thu, 12 Feb 1998 23:05:11 +0100

>Space and the Dual Ported RAM used to communicate with the CPM.

...and the IBM PPC403GC/GCX. Variable page sizes between 1k and 16M (in
eight steps, variable per TLB IIRC). This MMU, "designed for embedded apps"
according to IBM, also handles the process ID per TLB that Ralf mentioned
on the MIPS.

JDB (hunting for round tuits for that PPC board design)

Jan-Derk Bakker
Official Usenet Net.scum; see http://www.netscum.net