From owner-freebsd-stable@FreeBSD.ORG Thu May 22 07:18:54 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211C81065687 for ; Thu, 22 May 2008 07:18:54 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57006.mail.re3.yahoo.com (web57006.mail.re3.yahoo.com [66.196.97.110]) by mx1.freebsd.org (Postfix) with SMTP id C33A58FC29 for ; Thu, 22 May 2008 07:18:53 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 16819 invoked by uid 60001); 22 May 2008 07:18:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ha2emJ+QroxEcYECH21JrX8O+6mytk4SqzXnxdGvmSFBzLNpni1n6o866D2Xskp9tUpdpvohspYcSWhbREYWzxpTdE2SNn3ZCBndgmiTGb+aExzLEANnx33ag7qGgD/ywU2h5DlqqrS0DNMyaw/+k4ZHv05nArr1qcubT9ZRVOs=; X-YMail-OSG: Jy9FkEsVM1l1Mkl4WjfUYxBDQuH6PPEFfOVkKEUxwaD.ecoT_CqYHR7hwM0yQ.1ECzFncbcmUvqvpLjr_QOYKIIDGJAGaKCCFcW8bQ-- Received: from [165.21.154.112] by web57006.mail.re3.yahoo.com via HTTP; Thu, 22 May 2008 00:18:53 PDT Date: Thu, 22 May 2008 00:18:53 -0700 (PDT) From: Unga To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200805211817.m4LIHpbd024904@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <69853.16097.qm@web57006.mail.re3.yahoo.com> Cc: Oliver Fromme Subject: Re: sched_ule performance on single CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2008 07:18:54 -0000 --- Oliver Fromme wrote: > Sorry for the late reply, but I think there's a > technical > detail that should be mentioned ... > > Unga 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