From owner-freebsd-current Wed Apr 28 14:49: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0BDDD15520; Wed, 28 Apr 1999 14:48:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA09354; Wed, 28 Apr 1999 14:48:56 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Apr 1999 14:48:56 -0700 (PDT) From: Matthew Dillon Message-Id: <199904282148.OAA09354@apollo.backplane.com> To: Alan Cox Cc: Chuck Robey , Poul-Henning Kamp , Luoqi Chen , current@freebsd.org, smp@freebsd.org Subject: Re: HEADS UP! to commit SMP vmspace sharing patches References: <199904281819.LAA07937@apollo.backplane.com> <19990428151454.O1121@nonpc.cs.rice.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message