Messages in this thread | | | Date | Sat, 18 Apr 1998 16:17:49 +0200 | From | Andrej Presern <> | Subject | Re: 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
| |