Date: Sat, 5 Apr 1997 12:49:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gpalmer@freebsd.org (Gary Palmer) Cc: peter@spinner.dialix.com, cr@jcmax.com, smp@freebsd.org Subject: Re: Questions about mp_lock Message-ID: <199704051949.MAA23368@phaeton.artisoft.com> In-Reply-To: <12968.860260421@orion.webspan.net> from "Gary Palmer" at Apr 5, 97 12:13:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Peter Wemm wrote in message ID > <199704051704.BAA18422@spinner.DIALix.COM>: > > Moving the kernel locking up a layer and having a seperate entry/exit lock > > in the trap/syscall/interupt area would be a major win without too much > > cost. What we'd gain by that would be that we could then gradually move > > to a per-subsystem locking system perhaps based initially on which syscall > > or trap type. It'd be quite possible to have one cpu in the kernel doing > > IP checksumming on a packet, another in the vfs system somewhere, another > > doing some copy-on-write page copies in the vm system and so on. Things > > like getpid() would need no locking whatsoever. But that's for later once > > the basics are working. > > Question if you would: define`basics'? This is what I have called "stage one" in implementing fine grain parallelism. This is the first stage to a lock "push down" on a per subsystem basis (subsystems being accessed by system calls). It's not quite correct that you would go to a different lock for the system call entrancy vs. fault and interrupt entrancy of the kernel... doing that would probably make the job *much* harder because you would have to fine-grain protect all of the interrupt and fault code instantly to make it safe. Really, the trap code needs to be reeentrant to the point of the system call dispatch. Initially, you would add a per syscall flag into sysent[]. If the flag were not present, you would hold the global lock around the call; otherwise, you would expect the global lock to be held by the system call code, and the call head to be reentrant. You would then pick a divisable subsystem (my choice would be FS, but FS would be too large and you should pick something else if you aren't an FS geek), and "push" the reentrancy as far down the call graph as you could. To accomplish this, you would need to hold the global lock around context manipulation: kernel global pool manipulation, data objects like vnodes for which the value you are setting/getting must be accomplished atomically with the compare that proceeds or follows it, etc.. This will divide the call handling code into "safed" and "not safed" regions. Eventually, you will want to split out per subsystem locks with an "intention exclusive" mode held against the global lock. This will let you lock against subsystem reentrancy via system calls, and against fault and interrupt reentrancy otherwise. This implies a single lock hierarchy in which the global mutex is at the top, so that you can compute transitive closure over the hierarchy (to compute transitive closure just means that you will detect when a deadlock would occur if a lock were granted, and block the requestor until a deadlock was no longer a possibility). So the first step is probably a push-down on the global lock, not the creation of a seperate global lock. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704051949.MAA23368>