Date: Fri, 9 Feb 1996 18:20:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: zoogy@cris.com (Chad Shackley) Cc: hackers@freefall.freebsd.org Subject: Re: Multi-processor Message-ID: <199602100120.SAA11964@phaeton.artisoft.com> In-Reply-To: <199602092248.RAA14467@fs1.cris.com> from "Chad Shackley" at Feb 9, 96 02:51:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> What's the status of support for multi-processor machines? Are any > supported yet; are any being looked at? I have a dual-processor pentium > 100, and don't like the extra processor going to waste. An engineer at Intel is looking at making the locore.s changes I need to get the updated patches fully running in -current (so is Peter Wemm 8-)). He is going to send me mail when he has -current up and running on his box (which is, I think, a 4 processor Pentium Pro box), and I am going to send him my updated Jack Vogel patches. I just don't have the equipment (a two-ICE machine) to debug some of the code without writing a *significant* amount of assembly code. After this, there will be patches submitted immediately for integration for low grain paralellism of the type Jack had working (and still works if you apply his patches vs. a 28 Oct 95 checkout from CVS). For the next stage, kernel reeentrancy, there will have to be a lot of setup for kernel synchronization push down. This basically means moving the synchronization code for kernel reentrancy down below the trap and interrupt code. I haven't dealt with the issue of interrupt-time reentrancy... using a push-down, I can do the trap code seperately. Basically, the trap code requires instituting lock states at the system call layer, and then multithreading system calls a subsystem at a time. For the intermediate stage, this pretty much requires single entry/single exit for all routines called from the trap code so that each subsystem can be multithreaded independently without breaking the whole kernel and needing to fix everything at once. You do this by seperating out a subsystem mutex from the MP mutext for a multithreaded subsystem, and applying it in the trap entries for the calls into that subsystem. The file system framework is going to be a bear in this regard, and I expect to have to iterate the code several times to get the interfaces completely seperated out to avoid deadlock on things like vnode locks (which are currently held via VOP_LOCK on a per FS basis because of ihashget). To handle these cases, I think maybe the cache will have to be moved to a dev/offset instead of a vnode/offset. This gets rid of the inode/vnode layer dissociation in vclean() in vfs_subr.c, which means that the VOP_LOCK for vp's can become FS independent (if a union FS needs to lock a vp, it will have to lock the underlying vp's, so advisory VOP_LOCK calls to mostly null op's will still be needed -- but that can be done in the VLOCK/VUNLOCK inlines). The "biggie" will be implementing a hierarchical lock manager to avoid using real mutexes (which are expensive). It has to be hierarchical in order to compute transitive closure... deadlock detection would mean too many code changes because of the amount of state you need to unwind, so deadlock avoidance is a major design principle. I may just "punt" on the interrupt code, and let someone else work it out. I'm sure it will involve immediate requeue and virtualization. The actual interrupt handling should be via kernel thread (like "update" and the pager use, initially), instead of occuring at interrupt level (this is how NT, SVR4 ES/MP, and Solaris operate). Since the problems of kernel reeentrancy and kernel preemption are so very similar, I expect kernel multithreading (and therefore kernel threads) to just "drop out", if the code is written correctly. The overriding goal is to allow the SMP to "compile out" using macro substitution, while keeping the multithreading and reentrancy. Anyway, that's my status. 8-). 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?199602100120.SAA11964>