From owner-freebsd-stable@FreeBSD.ORG Sat May 24 01:37:47 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 905091065671 for ; Sat, 24 May 2008 01:37:47 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57010.mail.re3.yahoo.com (web57010.mail.re3.yahoo.com [66.196.97.114]) by mx1.freebsd.org (Postfix) with SMTP id 3CB6A8FC14 for ; Sat, 24 May 2008 01:37:47 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 1883 invoked by uid 60001); 24 May 2008 01:37:46 -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=V2n56v1cbUqKy2RFBqwp3DU22ilwZbx5WZM+oiqBnSalKGgif5hnAHUBCTA4zqsE77K7F47yBRuM3JFd0Bz+CG4huAVHpPR5cAwnW3SWACIWptvGDiiGWdOQh2F83YHb9TeCYdm+nv+6pBmwndR66zO11a3Wdw9zzvWPrLE6lII=; X-YMail-OSG: Fp_xhooVM1ltzyUB2i2KB1PTZbpcrzsVBVMMYLV1rttelqTDdeM0jbnx6bWawaGUZ5ClkoxluX12FmVPig1p_22HTsEdeDUATinSVQ-- Received: from [165.21.155.108] by web57010.mail.re3.yahoo.com via HTTP; Fri, 23 May 2008 18:37:46 PDT Date: Fri, 23 May 2008 18:37:46 -0700 (PDT) From: Unga To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200805231616.m4NGGNkK026611@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <555870.1659.qm@web57010.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: Sat, 24 May 2008 01:37:47 -0000 --- Oliver Fromme wrote: > Unga wrote: > > 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. > > I think it can. > > Opening a PDF causes quite a lot of I/O. The viewer > application has to be paged in from disk, all the > libraries and configuration files it uses, possibly > even parts of the X server have to be paged in, > depending on what features of the X protocol and > which extensions the viewer application uses. > And of course the PDF itself has to be loaded (which > might be not small), and finally all fonts used by > the PDF have to be loaded by the viewer application. > > On the other hand, the default buffer space of the > audio driver is quite small (the reason for that is > to reduce latency for sound effects in games). So > even a very short I/O congestion can cause an > audible > hiccup in audio playback or recording. > > > Using a faster processor or multi-core may solve > this > > problem, > > No, faster I/O hardware will solve it, or hardware > that better supports concurrent access. It's also > quite possible that improvements in FreeBSD's disk > system might solve the problem, i.e. by reordering > disk access in a more efficient manner, but this is > very non-trivial. But all of that is not a matter > of the process scheduler. > > Anotehr solution is to use more aggressive buffering > by either the audio application or the audio driver. > The latter can be set via sysctl. The former is a > matter of your audio application. > > I use mpg123 for mp3 playback on a 3-year old UP > machine. It has a buffer option which I use. > E.g. "mpg123 -b5000" will use 5 MB buffer; that's > enough for half a minute of audio. I do not use > renice, idprio, rtprio or anything, but still > audio playback works perfectly fine, even during > a buildworld. Or when opening a PDF. No hiccups. > Noted your points. 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? I wonder the issue I mentioned, open a pdf while playback audio, is it a issue on Apple Mac OSX? 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? Kind regards Unga