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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jim Gettys wrote:
> On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
>> * Pavel Machek <pavel@xxxxxx> wrote:
>>
>>>> Some day we may have modesetting support in the kernel for some 
>>>> graphics hw, right now it's pretty damn spotty.
>>> Yep, that's the way to go.
>> hey, i wildly supported this approach ever since 1996, when GGI came up
>> :-/
>>
> 
> So wildly you wrote tons of code.... ;-).
> 
> More seriously, at the time, XFree86 would have spat in your face for
> any such thing.  Thankfully, times are changing.
> 
> Also more seriously, a somewhat hybrid approach is in order for mode
> setting: simple mode setting isn't much code and is required for sane
> behavior on crash (it is nice to get oopses onto a screen); but the full
> blown mode setting/configuration problem is so large that on some
> hardware, it is likely left best left to a helper process (not the X
> server).
> 
> Also key to get sane behavior out of the scheduler is to get the X
> server to yield (sleep in the kernel) rather than busy waiting when the
> GPU is busy; a standardized interface for this for both fbdev and dri is
> in order.  Right now, X is a misbehaving compute bound process rather
> than the properly interactive process it can/should/will be, releasing
> the CPU whenever the hardware is busy. Needless to say, this wastes
> cycles and hurts interactivity with just about any scheduler you can
> devise. It isn't as if this is hard; on UNIX systems we did it in 1984
> or thereabouts.

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.
> 
> Of course, in 1996, XFree86 would have ignored any such interfaces, in
> its insane quest for operating system independent user space drivers
> requiring no standard kernel interfaces.... (it is the second part of
> this where the true insanity lay).
>                                   - Jim
> 


-- 
Bill Davidsen <davidsen@xxxxxxx>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux