[lkml]   [1998]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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


    Andrej Presern,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.021 / U:4.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site