Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Dominic Sweetman <dom@mips.com>
To: madprops@gmx.net
Cc: linux-mips@linux-mips.org
Subject: Re: tlb magic
Date: Sat, 25 Jun 2005 06:51:22 +0100	[thread overview]
Message-ID: <17084.61658.662352.432937@mips.com> (raw)
In-Reply-To: <18788.1118764826@www21.gmx.net>


Long ago...

> yes, I'm reading "See MIPS Run". So thanks for the online support that comes
> with it. Now, if I got it correctly, the exception routing described in
> section 6.7 uses per-process mappings for kseg2, i.e. that e.g. the first
> 2MB of (each) kseg2 are used  as page table of the corresponding process and
> maybe another few kb for process related stuff. Provided the page tables are
> continuously at the same address ( e.g. KSEG2_BASE ) a change of ASID in
> EntryHi would indeed make a change of the kseg2 pointer in Context
> unnecessary ( it always points to KSEG2_BASE ). The mapping of kseg2 would
> automatically change as the global bit is set to zero. 

Yes.  I think I recall that the first BSD4.3 ports for MIPS had a
fixed-virtual address per-process structure which was extended to
include the L2 page table.

> Using the standard page table approach I would now need an additional page
> table for each process in order to map those 2+x MB in kseg2 which I could
> put in kseg0/1 or in kseg2 with 'wired' TLB entries.
> 
> If that's the way to go - why is it only used in early BSD ports of like
> 1987 ? Are there any troubles with it or have other mechanisms turned out to
> be better for any reason ?

It's rather a lot of assumptions to build into architecture-dependent
code, not very flexible, not very SMP-friendly, and in other ways not
as scalable as one would like.

Current Linux systems accept more computation in the TLB miss
handler in order to use largely portable data structures for keeping
page tables.  You can always push at that trade-off...

--
Dominic Sweetman
MIPS Technologies

  parent reply	other threads:[~2005-06-25  5:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-13 14:06 tlb magic Mad Props
2005-06-13 20:59 ` Dominic Sweetman
2005-06-14 16:00   ` madprops
2005-06-14 17:18     ` Ralf Baechle
2005-06-25  5:51     ` Dominic Sweetman [this message]
2005-06-25 14:41       ` Ralf Baechle
2005-06-27 12:04         ` Maciej W. Rozycki

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=17084.61658.662352.432937@mips.com \
    --to=dom@mips.com \
    --cc=linux-mips@linux-mips.org \
    --cc=madprops@gmx.net \
    /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