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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 20 Mar 2007 10:44:44 -0400
From:	Bill Davidsen <davidsen@....com>
To:	jg@...top.org
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

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 <davidsen@....com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

-
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/