linux-kernel - Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Mar 2007 18:08:21 -0400
From:	Jim Gettys <jg@...top.org>
To:	Bill Davidsen <davidsen@....com>
Cc:	Ingo Molnar <mingo@...e.hu>, Pavel Machek <pavel@....cz>,
	Ash Milsted <thatistosayiseenem@...ab.com>,
	dmitry.torokhov@...il.com, Arkadiusz Miskiewicz <arekm@...en.pl>,
	linux-pm@...ts.osdl.org, Jens Axboe <jens.axboe@...cle.com>,
	linux-input@...ey.karlin.mff.cuni.cz,
	Alexey Starikovskiy <alexey.y.starikovskiy@...ux.intel.com>,
	linux-usb-devel@...ts.sourceforge.net,
	Jeff Chua <jeff.chua.linux@...il.com>,
	Meelis Roos <mroos@...ux.ee>,
	Janosch Machowinski <jmachowinski@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...sta.de>, linux-acpi@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Thomas Meyer <thomas.mey@....de>,
	"Michael S. Tsirkin" <mst@...lanox.co.il>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

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.

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.
                                - Jim

-- 
Jim Gettys
One Laptop Per Child


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/