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>