Date: Thu, 20 Dec 2001 13:43:28 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: Gilbert Gong <ggong@cal.alumni.berkeley.edu>, advocacy@FreeBSD.ORG, Jeremiah Gowdy <jeremiah@sherline.com> Subject: Re: Microsoft Advocacy? Message-ID: <XFMail.011220134328.jhb@FreeBSD.org> In-Reply-To: <023101c1899d$ae7bbc20$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Dec-01 Anthony Atkielski wrote: > John writes: > >> Well, 2 of them work for Apple, so they >> would probably go with OS X. > > Uh-oh. Do they have an employment contract with Apple that makes any code > they write anywhere property of Apple, or otherwise similarly endangers any > work they might do on FreeBSD? No. Stop being paranoid. >> How about the specific environment of working >> on software that runs on FreeBSD whether it be >> the kernel, userland tools, or KDE. > > In that specific and unusual situation, the best desktop is usually the > target OS for the development, unless you have multiple machines. It's not that unsual for people writing Unix software. >> This includes adding tweaks for uniprocessor >> boxes, for example. > > What sort of "tweaks"? Spin mutexes in the kernel don't need to actually have a lock to spin against since the disabling of interrupts that they perform is sufficient protection. This provides savings by avoiding the rather expensive atomic operations needed to implement a spin mutex. This actually benefits server performance on UP boxes as well, but I actually thought of this while trying to help out the performance of 5.0 on desktops (usually UP machines, most people don't have SMP desktops). >> In fact, the BSD scheduler actually prefers >> interactive user interface processes to >> background CPU-intensive "server" processes. > > So much for server performance, eh? > > How does it distinguish between the two? It doesn't, because they aren't that different. Get that thought into your head please. The way it works is that when a process performs I/O, it's priority gets bumped if it blocks waiting for I/O, and processes get "punished" for using the CPU. The more CPU they use, the more they get punished. Thus, processes that block on I/O a lot, including most user interactive programs and things like web servers, get a boost since we can run the CPU intensive programs while the I/O ones are waiting for I/O to complete. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220134328.jhb>