Messages in this thread | | | Subject | Re: Asynchronous read-ahead | Date | Tue, 09 Apr 1996 15:11:28 -0400 | From | Buddha Buck <> |
| |
OK, I'm subscribed to this list twice, so I can understand getting two copies of messages.
Why have I seen this one at least 6-10 times now (and probably more on the way.?
> bof@saarlink.de (Patrick Schaaf): > > > > Every task, even when cloned, currently gets its own TSS, and switches > > between tasks are done with a 'jmp TSS' instruction (see switch_to); > > this includes reloading CR3 from the new TSS, which initiates a TLB flush. > > True, but... > > > Optimizing it away, as David suggests, would mean to replace the > > 'jmp TSS' instruction with code that explicitly saves/restores state > > without modifying CR3; it might even save some other restoration work. > > I think this change would have minimal impact on other parts of > > the kernel; the switch_to is in exactly one place (schedule), setting > > up a new task might have to change, but nothing else. > > Actually, the hardware already does that optimization. If the cr3 value in the > new process is the same as the old cr3 value, the TLB's won't be flushed. > > (That's from intel documentation, not actual testing. I'm lazy). > > Linus > >
-- Buddha Buck bmbuck@acsu.buffalo.edu "She was infatuated with their male prostitutes, whose members were like those of donkeys and whose seed came in floods like that of stallions." -- Ezekiel 23:20
| |