lkml.org 
[lkml]   [1998]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Don't save registers during system calls
Alexander Kjeldaas wrote:
>
> 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.

You are right, it's not. It is a better way of enhancing performance of
the system though, that's why I mentioned it. My observation about small
system objects is indirectly connected to system calls because with
small objects the mechanism of a 'system call' too could be changed
(quite radically) to even further enhance the performance.

Not saving some registers at syscall will save you a few percent maybe.
Doing differential address space switches could save you a factor. So I
just thought it would be a good idea to mention it.

> 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/

Andrej

--
Andrej Presern, andrejp@luz.fe.uni-lj.si


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

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site