Date: Mon, 24 Apr 2000 09:33:29 -0600 From: Steve Passe <smp@csn.net> To: current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <200004241533.JAA04715@Ilsa.StevesCafe.com>
next in thread | raw e-mail | index | archive | help
Hi, > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? If you choose no, beware that without > this base cleanup there is *NO* chance whatsoever of any further SMP > work being MFC'd to 4.x. None. Zilch. It will have diverged too > much. As the original author of the cil/cml code I can say I was glad to see that Matt had finally put it to rest. It was a desperate hack made in an attempt to pinch a little more performance out of the paradigm without dealing with the whole spl() problem set. I would have done it myself if life hadn't taken me down a path where I have too little time for these things... I've been playing with test buildworlds on my server and have concluded that we are currently kernel (big giant lock?) bound. In my tests 3 CPUs actually complete buildworld faster than 4. The major solutions to SMP in the future will come from: 1: pushdown of the BGL into the read/write routines. 2: kernel threads. 3: replacement of spl() with mutex() type protection of data regions. I am guessing that little of the above will be MFC'd into 4.0. So the issue of the current SMP patch set should be based on its merits alone. I would agree that they in themselves are worthy of MFCing. Lets just not kid ourselves about major future improvements of SMP in 4.0, the biggies I enumerate above just won't happen there. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004241533.JAA04715>