Date: Sun, 25 May 2008 05:24:25 -0700 (PDT) From: Unga <unga888@yahoo.com> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sched_ule performance on single CPU Message-ID: <81954.15280.qm@web57005.mail.re3.yahoo.com> In-Reply-To: <35C9A4DD-3491-4850-92D5-CBE2BE4F814F@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Chuck Swiger <cswiger@mac.com> wrote: > On May 23, 2008, at 6:37 PM, Unga wrote: > > When open an pdf has two types of scenarios in > FreeBSD: > > 1. When X run as a realtime-prio process, X go mad > and swallow up > > almost all of CPU cycles, making audio hiccups. > > > > 2. When X run as a normal-prio process, X behaves > well and rarely > > gets an audible hiccup. > > > > Why X behave different under different priority > categories? Isn't > > this scheduler related? > > Sure. To generalize, the traditional scheduler goal > for Unix has been > to maximize overall throughput and avoid starvation > of even low- > priority tasks, at the expense of higher and > unpredictable latency. > Using realtime priority means that the kernel is > told to minimize > latency for that process even if it means starving > other processes of > CPU time. > > That is well suited for things like CD/DVD burning > or audio/visual > capture, but as you've experienced yourself, it does > poorly for > heavily client-server oriented stuff like X11's > architecture. > > > I wonder the issue I mentioned, open a pdf while > playback audio, is > > it a issue on Apple Mac OSX? > > Nope. :-) > > > Could somebody give some light here who uses an > Apple Mac OSX on > > this list? > > > > If it is not an issue in Mac OSX, how they have > overcome it then? > > > While both FreeBSD and MacOS X are general-purpose > operating systems, > doing multimedia creation and playback is among the > primary > functionality goals for MacOS X, in much the same > way that FreeBSD > regards providing "robust network services" like > Apache, DNS, email, > databases and so forth. > > Core Audio is probably the biggest user of realtime > thread scheduling > under MacOS X, followed by QuickTime or DVD playback > over Core Video. > These frameworks were designed to handle multimedia > without skipping > by preallocating sensible amounts of buffer space, > and they take > advantage of the Mach kernel and IOKit drivers which > are intended to > support realtime needs. Unlike the traditional BSD > kernels, the Mach > kernel was originally designed with SMP, soft & hard > realtime > scheduling in the kernel. The original userland > threads library which > came with Mach, called CThreads, was largely > responsible for the > design that was abstracted into the portable POSIX > threads model > widely used today. > > After FreeBSD 4, there has been a tremendous amount > of work in the > kernel on fine-grained locking and moving device > drivers from running > in the non-preemptable interrupt context to having > device kernel > threads which can be preempted, and there has also > been a lot of work > on the userland side to improve the C threading > libraries and to > improve multithreaded malloc() performance via > jemalloc, but this is > still ongoing and higher level applications like X11 > programs haven't > had years to adapt and take advantage of these > changes. > > Simple things like auto-tuning the size of the audio > buffers to avoid > or minimize skipping or dropouts isn't really in > place yet with > FreeBSD. Realtime video on FreeBSD is dependent > upon X11, which was > originally designed by a bunch of guys at MIT to be > able to display > lots of xterms or other things involving simple > blits of bits, > possibly over the network, in order to replace the > Andrew window > manager system used by CMU, MIT, IBM, and a few > others. X11 wasn't > designed to do alpha channel (aka transparency), > much less stream a > couple of hundred MB per second of data for realtime > OpenGL texturing > or video. (Although, Composite and GLX have since > been added to X11, > they are extensions rather than core functionality, > and hardware > driver support for GLX is less than perfectly > available, especially > once you start looking at the AMD64/EM64T platform, > rather than 32-bit > x86....) > > There's a 2002 BSDcon paper here, written around the > time of FreeBSD > 5.x's release, which has more details: > > http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ > Thank you very much for the detailed info. It seems FreeBSD may need two schedulers, one for desktop and one for server, among other things. Kind regards Unga
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81954.15280.qm>