Date: Mon, 16 Dec 1996 12:28:26 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Chuck Robey <chuckr@Glue.umd.edu> Cc: smp@freebsd.org Subject: Re: General SMP Design Message-ID: <Pine.SV4.3.95.961216120734.24818B-100000@parkplace.cet.co.jp> In-Reply-To: <Pine.OSF.3.95.961215220312.13518A-100000@gilligan.eng.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 15 Dec 1996, Chuck Robey wrote: > On Mon, 16 Dec 1996, Michael Hancock wrote: > > > http://www-dsg.stanford.edu/papers/non-blocking-osdi/index.html > > > > We have many examples of type-stable memory management in our code. i.e. > > a vnode is always an instance of a vnode, it can be a on a free list. It > > doesn't change it's type. The zone allocator is a good thing. > > I read that, but I don't clearly see why TSM was required. Not talking > about the benefits, but why it's required by NBS. Are you clearer, and > could you explain it without too much verbage (I don't want to make > everyone read a thesis here 8-> ). I'm still reading it myself, but I think it is because you don't want a data structure to change "underneath" you while other higher priority processes take over your lock and you retry later on. Type-stable memory simplifies implementation. SMP is complex, which why I think people should read good background material. Good infrastructure design can reduce complexity and improve performance at the same time. "UNIX Systems for modern architectures" by Schimmel and "UNIX Internals: the new frontiers" by Vahalia have the traditional approaches. When reading that stuff, you can't help wondering if there's a better way to do solve priority inversion, deadlocks, and all those other SMP problems. I don't know if NBS is a real silver bullet, but it's cool that find someone out there thinking about alternatives to what we know today. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961216120734.24818B-100000>