All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Shalayeff <mickey@lucifier.dial-up.user.akula.net>
To: hppa-linux@thepuffingroup.com
Cc: hppa-linux@thepuffingroup.com
Subject: Re: [hppa-linux] Picky details of TLB fault handlers
Date: Mon, 22 Mar 1999 12:41:52 -0500 (EST)	[thread overview]
Message-ID: <199903221741.MAA10607@lucifier.dial-up.user.akula.net> (raw)
In-Reply-To: <m10P9Bi-0007U1C@the-village.bc.nu> from Alan Cox at "Mar 22, 99 06:12:34 pm"

Making, drinking tea and reading an opus magnum from Alan Cox:
> > HP-UX does exactly this sort of thing for handling many traps and
> > interrupts.  It is fairly expensive, though, since you have to have
> > a stack on which to save the IPSW/IIAQ and probably a bunch of other
> > registers, and it's too much messing around for a TLB miss.
> 
> I'm right in assuming its legal to swap the return address - so the TLB
> handler can do a short piece of TLB handling for a present page miss,
> then stash the return into the kernel stack and rfi into the page fault handler
> so it will in turn return to the user context ?

i'd say that a miss handler would not _ever_ exceed 100 instructions total time
to successfully lookup and insert a missing translation into a tlb and
using just shadowed registers, so by doing that w/ all the interrupts
disabled (and keeping some data in direct-mapped segment) no need
to save even a single bit of context (since it's all in the shadows).
then the handler can save the whole context and call pagefault() routine to
process a complex page fault (ie one that has no translation
in the page table), since the whole context is saved it's safe to
receive any other page faults and/or interrupts.

this schema was first implemented in the lites (and mklinux later).
doing this way is like simulating the hardware TLB walker as present
on certain machines (712 at least, maybe any 7100lc, HP help!?)
there are certain constraints on page table organization, but
doing so would greatly speed up the tlb-walker equipped machines,
leaving the rest still in the best shape possible.
building a tlb-walker-ONLY kernel (as an option) may save about 10 other
instructions.

cu

-- 
    paranoic mickey       (my employers have changed but, the name has remained)

  reply	other threads:[~1999-03-22 18:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-22 17:05 [hppa-linux] Picky details of TLB fault handlers Bjorn Helgaas
1999-03-22 18:12 ` Alan Cox
1999-03-22 17:41   ` Michael Shalayeff [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-03-22 19:09 Bjorn Helgaas
1999-03-22 14:11 Christopher Neufeld

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=199903221741.MAA10607@lucifier.dial-up.user.akula.net \
    --to=mickey@lucifier.dial-up.user.akula.net \
    --cc=hppa-linux@thepuffingroup.com \
    --cc=mickey@openbsd.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.