Date: Thu, 22 May 2008 00:18:53 -0700 (PDT) From: Unga <unga888@yahoo.com> To: freebsd-stable@FreeBSD.ORG Cc: Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: sched_ule performance on single CPU Message-ID: <69853.16097.qm@web57006.mail.re3.yahoo.com> In-Reply-To: <200805211817.m4LIHpbd024904@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Oliver Fromme <olli@lurza.secnetix.de> wrote: > Sorry for the late reply, but I think there's a > technical > detail that should be mentioned ... > > Unga <unga888@yahoo.com> wrote: > > My earlier test shows processes in the normal > category > > can starve processes in real-time category. > That's > > alarming. It should be get fixed. > > Note that FreeBSD does not support "hard real time" > processing. Strictly speaking no OS does that on PC > standard hardware. > > FreeBSD's idprio/rtprio implementation only affects > the decisions of the scheduler, i.e. the assignment > of CPU time slices to processes. However, there are > other resources beside CPU that influence the > execution > of processes. For example disk I/O. > > In other words, if an idle-prio process performs a > lot > of disk accesses, it creates an I/O bottleneck, and > even realtime-prio processes will have to wait > because > the hardware (disk) is blocked. This problem can be > alleviated by using faster and better hardware, e.g. > a SCSI RAID-0 disk subsystem or whatever. Besides, > for professional audio recording you will also need > professional audio hardware (which should include > its > own buffer memory, among other things), not a > consumer > card or an el'cheapo USB dongle. > > Best regards > Oliver > > PS: My notebook at home (Pentium-M, UP, 3 years > old) > works very well with FreeBSD/i386 RELENG_7 + > SCHED_ULE. > Idle-prio process which generates lot of I/O is understandable. But when you either record or playback audio as realtime-prio and you opened up a pdf document as normal-prio, can the pdf rendering in normal-prio breaks down the realtime audio process? I don't think pdf rendering is I/O intensive. Using a faster processor or multi-core may solve this problem, but my question is, can smart scheduling solve it without buying more processors? Kind regards Unga
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69853.16097.qm>