From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933537AbXCTOnx (ORCPT ); Tue, 20 Mar 2007 10:43:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933535AbXCTOnx (ORCPT ); Tue, 20 Mar 2007 10:43:53 -0400 Received: from mail.tmr.com ([64.65.253.246]:44587 "EHLO gaimboi.tmr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753358AbXCTOnv (ORCPT ); Tue, 20 Mar 2007 10:43:51 -0400 Message-ID: <45FFF35C.20003@tmr.com> Date: Tue, 20 Mar 2007 10:44:44 -0400 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061105 SeaMonkey/1.0.6 MIME-Version: 1.0 To: jg@laptop.org CC: Ingo Molnar , Pavel Machek , Ash Milsted , dmitry.torokhov@gmail.com, Arkadiusz Miskiewicz , linux-pm@lists.osdl.org, Jens Axboe , linux-input@atrey.karlin.mff.cuni.cz, Alexey Starikovskiy , linux-usb-devel@lists.sourceforge.net, Jeff Chua , Meelis Roos , Janosch Machowinski , Linux Kernel Mailing List , Adrian Bunk , linux-acpi@vger.kernel.org, "Eric W. Biederman" , Thomas Meyer , "Michael S. Tsirkin" , Andrew Morton , Linus Torvalds Subject: Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions References: <20070305015034.GG3441@stusta.de> <20070308123143.GF5149@mellanox.co.il> <20070308192554.GA2999@elte.hu> <20070308230705.GA4611@elte.hu> <20070309111957.GA3928@elf.ucw.cz> <20070318160707.GC12673@elte.hu> <1174236045.6832.9.camel@localhost> <45FEF395.9050409@tmr.com> <1174342101.6832.173.camel@localhost> In-Reply-To: <1174342101.6832.173.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jim Gettys wrote: > On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote: > > >> What you say sounds good, assuming that the cost of a sleep is less than >> the cost of the busy wait. But this may be hardware, the waits may be >> very small and frequent, and if it's hitting a small hardware window >> like retrace, delays in response will cause the time period to be missed >> completely. This probably less critical with very smart cards, many of >> us don't run them. >> > > Actually, various strategies involving short busy waiting, or looking at > DMA address registers before sleeping were commonplace. But a > syscall/sleep/wakeup is/was pretty fast. If you have an operation > blitting the screen (e.g. scrolling), it takes a bit of time for the GPU > to execute the command. I see this right now on OLPC, where a wonderful > music application needs to scroll (most of) the screen left), > periodically, and we're losing samples sometimes at those operation. > None of that conflicts with what I said, but what works on an LCD may not be appropriate for a CRT. With even moderate 1024x768@70 timing the horizontal retrace happens ~50k/sec, and that's not an appropriate syscall rate. I'm just pointing out that some things a video interface does with simple hardware involve lots of very small windows. Don't read that as "don't do it," just "be careful HOW you do it." > Remember also, that being nice to everyone else by sleeping, there are > more cycles to go around, and the scheduler can nicely boost the X > server's priority as it will for "interactive" processes that are being > cooperative. I'm going to cautiously guess that the problem might be not "how much" but "how soon." That is, latency might be more important than giving the server a lot of CPU. -- bill davidsen CTO TMR Associates, Inc Doing interesting things with small computers since 1979