Date: Wed, 14 Jul 1999 01:29:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: the_hermit665@hotmail.com, freebsd-smp@FreeBSD.ORG Subject: Re: SMP comparisons Message-ID: <199907140129.SAA22268@usr02.primenet.com> In-Reply-To: <199907081641.JAA40947@apollo.backplane.com> from "Matthew Dillon" at Jul 8, 99 09:41:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> :NO!!!!! FreeBSD is ahead... maybe behind a little... either way, we kick > :linux's A$$ > : > :p.s. I gave a copy of 3.0 to a friend of mine to compare between linux & > :FreeBSD on SMP and maybe even NT. I'll be hearing back from him on thouse > :results. The question was "other free or commercial OS's". INRE to commercial OS's, SVR4.0.2 ES/MP from ~1993 still beats FreeBSD, hands down. > Linux beats our arses on SMP performance, I'm afraid. They've been > able to move the tcp stack outside of the big giant lock and have also > moved a significant portion of the data copying stuff outside of the > big giant lock. It's been a while since I've sat down and had a hard look at Linux internals, but the last time I looked, Linux prevalidated address ranges for data transfer via their copyin/copyout equivalents. This has a significant downside in an SMP environment (the only way I could see to fix this would be to rip it out), and can even be a problem in a kernel threaded environment, where another thread or processor could modify the address space contents during a slept call. Technically, you won't run into trouble until someone attempts to exploit the hole, but when that happens, you will be well and truly screwed. I need to take a look at what they did with the TCP stack, but it seems to me that it's possible to deal with the stack issues in FreeBSD rather trivially. From the descriptions of their new architecture I've read, the big win was one of concurrency -- even in a UP kernel, they were unable to have multiple simultaneous requests outstanding. This leads to obvious latency issues that arise from an increased pool retention time (e.g. a fundamental ignorance of queueing theory in the initial design). This will help them on the ZD Labs and other NT vs. Linux benchmarks, but will do little for overall load bearing characteristics. > And, on top of that, we need to make significant > changes to the way our buffer cache works to even approach linux's > I/O performance under SMP. I agree with this, but not for the reasons you state below. I agree because of the cache inaccessiblity for update leading to stalling. The stuff Kirk was reported to be doing will help this somewhat, and intention mode locking with handoff for non-reschedulable buffers (e.g. those containing a soft updates transaction backout) would help this significantly. > I want to move us more towards a UVM model for I/O - i.e. going > through the VM subsystem to read and write data rather then VFS > subsystem and the notifying the VFS system after the fact for writes. I don't think that's really necessary. Most of the code for the VOP_GETPAGES and VOP_PUTPAGES already addresses this I/O path. The main issue that has to be addressed in this regard has got to be non-page aligned copy overhead, which necessitates a copy instead of a handoff (at the expense of reinstancing the data and/or using memory protection for copy-on-write semantics for what is nominally the processes data address space). This is going to be a problem so long as there are buffers in user programs. > Unfortunately, I doubt that much progress will be made in the current > environment. ??? > FreeBSD still kicks ass in the reliability department, despite the > recent problems with INN and mmap(), and FreeBSD still kicks ass if > a system ever has to start paging. Paging performance is a fallout of a unified VM and buffer cache. The mmap() issue still has me concerned. I am still of the opinion that, given an OS with a truly unified VM and buffer cache, it should not be necessary for the INN code to call msync(), which is used to implement a user-level cache coherency protocol, and is (supposedly) irrelevent in a unified environment. I think another issue in this regard is the (IMO) ill-considered attempt to make vnodes and VM objects semi-synonymous; the real issue that needs to be dealt with is slow (file) vs. medium (swap) vs. fast (RAM) backing store. The idea, which you expressed earlier, that coherency notification needs to be explicitly called out, is counter-intuitive to me. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907140129.SAA22268>