Re: Don't save registers during system calls

Alexander Kjeldaas (astor@guardian.no)
Sat, 18 Apr 1998 14:48:50 +0200

On Fri, Apr 17, 1998 at 01:25:23AM +0200, Andrej Presern wrote:
>
> It's not really a question whether to save registers during system calls
> but rather the amount of TLB flushing and restoring at virtual address
> switch. If instead of the whole TLB only a few entries are changed, a
> lot of performance could be won since changing an individual entry in
> the TLB is a lot cheaper than flushing and reloading the TLB.
>
> This method however requires small objects and Linux doesn't know about
> small objects since the objects can assume whole virtual address space.
> An alternative operating system model that favours the small address
> space is a pure capabilities based one. Note that since faster address
> space switching means that the border of authority is becoming cheaper
> to cross, it doesn't really matter that much anymore how often we cross
> the border. Such a change would result in small system objects that
> could provide a virtually arbitrarily fine-grained control while still
> gaining us some performance.

I'm not sure I understand the above. Unless I've misunderstood, the
TLB isn't an issue on a simple system call.

The border I'm talking about is the user<->kernel border. We don't do
_anything_ to the TLB when crossing that border. At least not on
decent RISC chips with block translation capabilities (maybe you have
to do some weird things to accomodatestupid caches like the
MIPS). It's not a virtual address switch as you call it. All memory
accesses to in-kernel datastructures go through one of the block
translation entries in the CPU, bypassing the TLB. Accesses to
user-space will go through the TLB but probably with a 99.9% chance of
a TLB hit.

Kernel memory (or physical memory) is always "mapped in", even in
user-space. But you're not allowed to access it unless you're in
supervisor mode (or some ring < user-level ring on intel/HP).

So this leaves the TLB unchanged from entry to exit from a system call
provided we didn't do a schedule() in the kernel.

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu