:On Wed, Apr 28, 1999 at 11:19:17AM -0700, Matthew Dillon wrote:
:> I know this is a little late ... but I don't suppose there might be a
:> way to lock a TLB entry in place? That would solve the problem too.
:> Baring that, %fs is the way to go.
:>
:
:Unfortunately, on the x86, the answer is "No." The only serious
:alternative was to put the commonly used per processor variables
:and a pointer to the less commonly used ones at the base of each
:process's/thread's kernel stack, i.e., the upages, where you could
:mask off bits from the stack pointer to arrive at the correct address.
:You'd then have to "refresh" most of these variables on a context switch
:(in case the process migrated).
:
: Alan
Too bad.
There might be less confusion with %fs if we simply use it as a
'cpu number' index and then make all the cpu-dependant variables
standard arrays. i.e. instead if 'struct proc *curproc' we would
have 'struct proc *curproc[NCPU];'. The assembly macro would
simply retrieive the current cpu number from %fs, so:
curproc[MYCPU] = ...
This would be much less confusing then trying to encapsulate the concept
of 'curproc', and we could do away with cpu-specific VM areas entirely.
Sure, it would eat a few more cycles, but I don't think it would effect
performance.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
