sched_ule performance on single CPU
unga888 at yahoo.com
Thu May 22 07:18:54 UTC 2008
--- Oliver Fromme <olli at lurza.secnetix.de> wrote:
> Sorry for the late reply, but I think there's a
> detail that should be mentioned ...
> Unga <unga888 at yahoo.com> wrote:
> > My earlier test shows processes in the normal
> > can starve processes in real-time category.
> > 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
> of processes. For example disk I/O.
> In other words, if an idle-prio process performs a
> of disk accesses, it creates an I/O bottleneck, and
> even realtime-prio processes will have to wait
> 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
> own buffer memory, among other things), not a
> card or an el'cheapo USB dongle.
> Best regards
> PS: My notebook at home (Pentium-M, UP, 3 years
> works very well with FreeBSD/i386 RELENG_7 +
Idle-prio process which generates lot of I/O is
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?
More information about the freebsd-stable