lkml.org 
[lkml]   [1996]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Asynchronous read-ahead
Date
From

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




\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.060 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site