WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[gaxt]

Kudos to CK

In 2.4.21 galciv + wine was fine.

In 2.4.21 + CK patches, galvic + wine would pause every 15 seconds or so 
(maybe it was when little animations played).

In 2.6.0-test1-mm2 (vanilla, or + 08) Galciv would stutter horribly and 
freeze my machine in wine. It might run smoothly until I loaded a 
nautilus window or something then stutters and loss of control of the 
system.

With 09, it is smooth as silk until I do something and then the video 
playbacks can be choppy but the game (turn based strategy) seems to run 
without the long pauses of 2.4.21 CK or 2.6.0 vanilla. I can switch 
between apps and go back without any problem.

09 seems to be a big improvement for whatever caused the stutter & die 
problems in wine+galciv.

Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[Con Kolivas]

On Sun, 27 Jul 2003 07:49, gaxt wrote:
> Kudos to CK

Thanks.

> In 2.4.21 galciv + wine was fine.
>
> In 2.4.21 + CK patches, galvic + wine would pause every 15 seconds or so
> (maybe it was when little animations played).
>
> In 2.6.0-test1-mm2 (vanilla, or + 08) Galciv would stutter horribly and
> freeze my machine in wine. It might run smoothly until I loaded a
> nautilus window or something then stutters and loss of control of the
> system.
>
> With 09, it is smooth as silk until I do something and then the video
> playbacks can be choppy but the game (turn based strategy) seems to run
> without the long pauses of 2.4.21 CK or 2.6.0 vanilla. I can switch
> between apps and go back without any problem.
>
> 09 seems to be a big improvement for whatever caused the stutter & die
> problems in wine+galciv.

Therein lies the problem with large MAX_SLEEP_AVG values. It may prevent 
interactive tasks from becoming non interactive (which is the point), but if 
an interactive task turns into a true cpu hog it can literally stall the 
machine for seconds. Which is why the workaround in O*int that allow small 
MSAs help.

Con

260test2+O10int breaks : Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[gaxt]

Update: 260-test2 with O10int has returned wine+galciv to freezing the 
whole computer on starting the game. The intro avi plays less than 1 
second and the machine freezes up. I can swtich from virtual terminals 
but not enter any input.

Con Kolivas wrote:
> On Sun, 27 Jul 2003 07:49, gaxt wrote:
> 
>>Kudos to CK
> 
> 
> Thanks.
> 
> 
>>In 2.4.21 galciv + wine was fine.
>>
>>In 2.4.21 + CK patches, galvic + wine would pause every 15 seconds or so
>>(maybe it was when little animations played).
>>
>>In 2.6.0-test1-mm2 (vanilla, or + 08) Galciv would stutter horribly and
>>freeze my machine in wine. It might run smoothly until I loaded a
>>nautilus window or something then stutters and loss of control of the
>>system.
>>
>>With 09, it is smooth as silk until I do something and then the video
>>playbacks can be choppy but the game (turn based strategy) seems to run
>>without the long pauses of 2.4.21 CK or 2.6.0 vanilla. I can switch
>>between apps and go back without any problem.
>>
>>09 seems to be a big improvement for whatever caused the stutter & die
>>problems in wine+galciv.
> 
> 
> Therein lies the problem with large MAX_SLEEP_AVG values. It may prevent 
> interactive tasks from becoming non interactive (which is the point), but if 
> an interactive task turns into a true cpu hog it can literally stall the 
> machine for seconds. Which is why the workaround in O*int that allow small 
> MSAs help.
> 
> Con
> 
> 

Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[Con Kolivas]

On Tue, 29 Jul 2003 07:40, gaxt wrote:
> 260-test2-vanilla works fine with a little stutter playing the avis
> 260-test2-O10 causes horrible stutter and loss of input to system
> 260-test2-mm1 causes horrible stutter and loss of input to system
>
> NOTE: Instead of re-setting, by switching consoles by pressing Alt F7
> then Alt-F1 back and forth (ie from X to virtual console) it seems I
> could prod wine+galciv into edging forward, stalling, edging forward
> etc. through the opening AVIs. ie. I would hear the sounds of the movie
> advance each time  I switched into Alt-F1.
>
> Once into the turn-based game itself (after opening animations) ability
> to input was restored again and the game can be played and windows moved
> around etc.
>
> So it seems the playing of the little movies is what really locks up the
> whole system using the O10/mm1 scheduling???

File I/O ? Try booting with elevator=deadline

Con

Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[gaxt]

260-test2-vanilla works fine with a little stutter playing the avis
260-test2-O10 causes horrible stutter and loss of input to system
260-test2-mm1 causes horrible stutter and loss of input to system

NOTE: Instead of re-setting, by switching consoles by pressing Alt F7 
then Alt-F1 back and forth (ie from X to virtual console) it seems I 
could prod wine+galciv into edging forward, stalling, edging forward 
etc. through the opening AVIs. ie. I would hear the sounds of the movie 
advance each time  I switched into Alt-F1.

Once into the turn-based game itself (after opening animations) ability 
to input was restored again and the game can be played and windows moved 
around etc.

So it seems the playing of the little movies is what really locks up the 
whole system using the O10/mm1 scheduling???

Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[gaxt]

Con Kolivas wrote:
> On Tue, 29 Jul 2003 07:40, gaxt wrote:
> 
>>260-test2-vanilla works fine with a little stutter playing the avis
>>260-test2-O10 causes horrible stutter and loss of input to system
>>260-test2-mm1 causes horrible stutter and loss of input to system
>>
>>NOTE: Instead of re-setting, by switching consoles by pressing Alt F7
>>then Alt-F1 back and forth (ie from X to virtual console) it seems I
>>could prod wine+galciv into edging forward, stalling, edging forward
>>etc. through the opening AVIs. ie. I would hear the sounds of the movie
>>advance each time  I switched into Alt-F1.
>>
>>Once into the turn-based game itself (after opening animations) ability
>>to input was restored again and the game can be played and windows moved
>>around etc.
>>
>>So it seems the playing of the little movies is what really locks up the
>>whole system using the O10/mm1 scheduling???
> 
> 
> File I/O ? Try booting with elevator=deadline
> 
> Con

Setting elevator=deadline results in wine+galciv loading without the 
horrible long pauses but there is still chugging and while the AVIs 
play, the rest of Gnome is unresponsive (ie can't switch windows by 
clicking etc) though I can switch to Alt-F1 virtual terminal. Still not 
as good as 260-test-2-vanilla

Re: WINE + Galciv + Con Kolivar's 09 patch to 2.6.0-test1-mm2

[Con Kolivas]

On Tue, 29 Jul 2003 12:30, gaxt wrote:
> Con Kolivas wrote:
> > File I/O ? Try booting with elevator=deadline
>
> Setting elevator=deadline results in wine+galciv loading without the
> horrible long pauses but there is still chugging and while the AVIs
> play, the rest of Gnome is unresponsive (ie can't switch windows by
> clicking etc) though I can switch to Alt-F1 virtual terminal. Still not
> as good as 260-test-2-vanilla

Well that is weird, but no doubt IO is playing some part here. Can you please 
try the preview O11 patch (incremental against 2.6.0-test2-mm1 but should 
patch against an O10 patched vanilla) in 

http://kernel.kolivas.org/2.5/experimental

While not specifically addressing this problem, it may help.

Con

Re: WINE + Galciv + Con Kolivas's 011 patch to 2.6.0-test2

[Con Kolivas]

On Tue, 29 Jul 2003 22:48, gaxt wrote:
> I tried O11. Still chuggy in the AVIs and then locks out input into X. I
> switch to Alt-F1 console and hear the video advance, switch back, it
> pauses, switch to Alt-F1 etc. to get it through the video and then it's
> fine.
>
> Incidentally, I moved my /home to another hard drive last night (same
> 7200 rpms) to get more space. It makes no difference to performance.
> 260-test2-vanilla was quite good and -mm1 and -O11 are chuggy and lock
> out input to X and require switching to virtual console to advance
> through the videos.
>
> If there is some other data I can provide you, let me know.

What top shows as the PRI of all the important processes concerned during all 
this would be helpful.

Con

Re: WINE + Galciv + Con Kolivas's 011 patch to 2.6.0-test2

[gaxt]

I tried O11. Still chuggy in the AVIs and then locks out input into X. I 
switch to Alt-F1 console and hear the video advance, switch back, it 
pauses, switch to Alt-F1 etc. to get it through the video and then it's 
fine.

Incidentally, I moved my /home to another hard drive last night (same 
7200 rpms) to get more space. It makes no difference to performance. 
260-test2-vanilla was quite good and -mm1 and -O11 are chuggy and lock 
out input to X and require switching to virtual console to advance 
through the videos.

If there is some other data I can provide you, let me know.

Con Kolivas wrote:
> On Tue, 29 Jul 2003 12:30, gaxt wrote:
> 
>>Con Kolivas wrote:
>>
>>>File I/O ? Try booting with elevator=deadline
>>
>>Setting elevator=deadline results in wine+galciv loading without the
>>horrible long pauses but there is still chugging and while the AVIs
>>play, the rest of Gnome is unresponsive (ie can't switch windows by
>>clicking etc) though I can switch to Alt-F1 virtual terminal. Still not
>>as good as 260-test-2-vanilla
> 
> 
> Well that is weird, but no doubt IO is playing some part here. Can you please 
> try the preview O11 patch (incremental against 2.6.0-test2-mm1 but should 
> patch against an O10 patched vanilla) in 
> 
> http://kernel.kolivas.org/2.5/experimental
> 
> While not specifically addressing this problem, it may help.
> 
> Con
> 
> 

Re: WINE + Galciv + Con Kolivas's 011 patch to 2.6.0-test2

[gaxt]

Con Kolivas wrote:
> On Tue, 29 Jul 2003 22:48, gaxt wrote:
> 
>>I tried O11. Still chuggy in the AVIs and then locks out input into X. I
>>switch to Alt-F1 console and hear the video advance, switch back, it
>>pauses, switch to Alt-F1 etc. to get it through the video and then it's
>>fine.
>>
>>Incidentally, I moved my /home to another hard drive last night (same
>>7200 rpms) to get more space. It makes no difference to performance.
>>260-test2-vanilla was quite good and -mm1 and -O11 are chuggy and lock
>>out input to X and require switching to virtual console to advance
>>through the videos.
>>
>>If there is some other data I can provide you, let me know.
> 
> 
> What top shows as the PRI of all the important processes concerned during all 
> this would be helpful.
> 
> Con

It's hard to grab top info as the interface freezes up. I'd have to ssh 
in from another system.

However, browsing lkml, I noticed someone saying I/O throughput was 
affected by a readahead setting of 256 instead of 512 using hdparm -a 
###. I changed the readahead on my root and home drives and galciv was 
able to load (with some mild stuttering in the movies).

I've never adjusted this setting before. Perhaps it compensates for 
scheduler activity by allowing the system to draw more data within a 
given timeslice? Or am I babbling?

Running top while glaciv + wine is running with the new hdparm -a 512 
setting, I can mention the following patterns:

When loading up playing AVIs, the top are wineserver, wine, wine, and X 
(there is also another wine process). When the game chugs/pauses badly 
in playing an avi, wineserver leaps to the top with >50% CPU with 
wineserver+wine processes+x taking 100% CPU. Then when chugging lapses, 
wineserver drops down to the 26% range and the other wine processes are 
the same or a bit above. When the game is loaded, two wine processes at 
21% CPU each are at top, then X with 5-10% then wineserver with 2-3% (a 
huge drop) or even a couple of appas above wineserver.

Perhaps this data helps?

Re: WINE + Galciv + Con Kolivas's 011 patch to 2.6.0-test2

[gaxt]

More notes.

galciv+wine even with hdparm -a is still too chuggy even within the 
game. Wineserver drops down to a 1-3% in game play but wine processes +x 
add up to 95 - 100% and slows things down. Using other windows in X 
takes long pauses. Not like vanilla 260 at all which was very smooth in 
the game and switching between apps.

gaxt wrote:
> Con Kolivas wrote:
> 
>> On Tue, 29 Jul 2003 22:48, gaxt wrote:
>>
>>> I tried O11. Still chuggy in the AVIs and then locks out input into X. I
>>> switch to Alt-F1 console and hear the video advance, switch back, it
>>> pauses, switch to Alt-F1 etc. to get it through the video and then it's
>>> fine.
>>>
>>> Incidentally, I moved my /home to another hard drive last night (same
>>> 7200 rpms) to get more space. It makes no difference to performance.
>>> 260-test2-vanilla was quite good and -mm1 and -O11 are chuggy and lock
>>> out input to X and require switching to virtual console to advance
>>> through the videos.
>>>
>>> If there is some other data I can provide you, let me know.
>>
>>
>>
>> What top shows as the PRI of all the important processes concerned 
>> during all this would be helpful.
>>
>> Con
> 
> 
> It's hard to grab top info as the interface freezes up. I'd have to ssh 
> in from another system.
> 
> However, browsing lkml, I noticed someone saying I/O throughput was 
> affected by a readahead setting of 256 instead of 512 using hdparm -a 
> ###. I changed the readahead on my root and home drives and galciv was 
> able to load (with some mild stuttering in the movies).
> 
> I've never adjusted this setting before. Perhaps it compensates for 
> scheduler activity by allowing the system to draw more data within a 
> given timeslice? Or am I babbling?
> 
> Running top while glaciv + wine is running with the new hdparm -a 512 
> setting, I can mention the following patterns:
> 
> When loading up playing AVIs, the top are wineserver, wine, wine, and X 
> (there is also another wine process). When the game chugs/pauses badly 
> in playing an avi, wineserver leaps to the top with >50% CPU with 
> wineserver+wine processes+x taking 100% CPU. Then when chugging lapses, 
> wineserver drops down to the 26% range and the other wine processes are 
> the same or a bit above. When the game is loaded, two wine processes at 
> 21% CPU each are at top, then X with 5-10% then wineserver with 2-3% (a 
> huge drop) or even a couple of appas above wineserver.
> 
> Perhaps this data helps?
> 

Re: WINE + Galciv + Con Kolivas's 011 patch to 2.6.0-test2

[gaxt]

gaxt wrote:
> More notes.
> 
> galciv+wine even with hdparm -a is still too chuggy even within the 
> game. Wineserver drops down to a 1-3% in game play but wine processes +x 
> add up to 95 - 100% and slows things down. Using other windows in X 
> takes long pauses. Not like vanilla 260 at all which was very smooth in 
> the game and switching between apps.

sorry -> 260-test2 vanilla NOT 260test1 which would lock galciv+wine up.

> 
> gaxt wrote:
> 
>> Con Kolivas wrote:
>>
>>> On Tue, 29 Jul 2003 22:48, gaxt wrote:
>>>
>>>> I tried O11. Still chuggy in the AVIs and then locks out input into 
>>>> X. I
>>>> switch to Alt-F1 console and hear the video advance, switch back, it
>>>> pauses, switch to Alt-F1 etc. to get it through the video and then it's
>>>> fine.
>>>>
>>>> Incidentally, I moved my /home to another hard drive last night (same
>>>> 7200 rpms) to get more space. It makes no difference to performance.
>>>> 260-test2-vanilla was quite good and -mm1 and -O11 are chuggy and lock
>>>> out input to X and require switching to virtual console to advance
>>>> through the videos.
>>>>
>>>> If there is some other data I can provide you, let me know.
>>>
>>>
>>>
>>>
>>> What top shows as the PRI of all the important processes concerned 
>>> during all this would be helpful.
>>>
>>> Con
>>
>>
>>
>> It's hard to grab top info as the interface freezes up. I'd have to 
>> ssh in from another system.
>>
>> However, browsing lkml, I noticed someone saying I/O throughput was 
>> affected by a readahead setting of 256 instead of 512 using hdparm -a 
>> ###. I changed the readahead on my root and home drives and galciv was 
>> able to load (with some mild stuttering in the movies).
>>
>> I've never adjusted this setting before. Perhaps it compensates for 
>> scheduler activity by allowing the system to draw more data within a 
>> given timeslice? Or am I babbling?
>>
>> Running top while glaciv + wine is running with the new hdparm -a 512 
>> setting, I can mention the following patterns:
>>
>> When loading up playing AVIs, the top are wineserver, wine, wine, and 
>> X (there is also another wine process). When the game chugs/pauses 
>> badly in playing an avi, wineserver leaps to the top with >50% CPU 
>> with wineserver+wine processes+x taking 100% CPU. Then when chugging 
>> lapses, wineserver drops down to the 26% range and the other wine 
>> processes are the same or a bit above. When the game is loaded, two 
>> wine processes at 21% CPU each are at top, then X with 5-10% then 
>> wineserver with 2-3% (a huge drop) or even a couple of appas above 
>> wineserver.
>>
>> Perhaps this data helps?
>>
> 
> 

2.6.0-test2-mm5 + July Wine + Galciv

[gaxt]

As an update to the messages I've been posting about running Galactic 
Civ in Wine on the 260 series:

260-test2-mm5 seems quite nice.

When programs are intially run (ie. Nautilus, OpenOffice etc. as well as 
Galciv in wine) there can be minor stuttering and some long delays but 
once the software is up, it can be switched back and forth with little 
problem. (When initially starting up even the movies ran fine without 
pauses)

There can be some minor stuttering when flipping between apps but it 
seems to smooth out after using a particular app for awhile which I 
would guess is the adpative nature of the scheduler?

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Con Kolivas]

On Wed, 13 Aug 2003 00:42, gaxt wrote:
> Photoshop 6 (yes, legal owned version) in wine is flawless (as it was
> with 2.6.0-test3)
>
> Galciv plays videos quite smoothly but as soon as I run it it will
> freeze the cursor for 12-15 seconds every half-minute or so even within
> the game itself which is turn-based strategy without a lot of whizbang
> stuff. In the past, the videos would stutter but the game would not
> suffer from more than short pauses now and then.

Yes, herein lies one of those mysteries that still eludes me but I have been 
investigating it. I can now reproduce in other applications what appears to 
be the problem - Two cpu hogs, X and evolution for example are running and 
evolution is making X the cpu hog. The problem is that X gets demoted whereas 
evolution doesn't. Strangely, dropping evolution to nice +1 or making X -1 
seems to change which one gets demoted, and X is now much smoother. I assume 
the same thing is happening here between wine and wineserver, which is why 
you've seen reversal of priorities in your previous posts. See if renicing 
one of them +1 helps for the time being. I will continue investigating to 
find out why the heck this happens and try and fix it.

Con

P.S. I've cc'ed MG because he has seen the scheduler do other forms of 
trickery and may have thoughts on why this happens.

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[gaxt]

Photoshop 6 (yes, legal owned version) in wine is flawless (as it was 
with 2.6.0-test3)

Galciv plays videos quite smoothly but as soon as I run it it will 
freeze the cursor for 12-15 seconds every half-minute or so even within 
the game itself which is turn-based strategy without a lot of whizbang 
stuff. In the past, the videos would stutter but the game would not 
suffer from more than short pauses now and then.

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Mike Galbraith]

At 12:40 AM 8/13/2003 +1000, Con Kolivas wrote:
>On Wed, 13 Aug 2003 00:42, gaxt wrote:
> > Photoshop 6 (yes, legal owned version) in wine is flawless (as it was
> > with 2.6.0-test3)
> >
> > Galciv plays videos quite smoothly but as soon as I run it it will
> > freeze the cursor for 12-15 seconds every half-minute or so even within
> > the game itself which is turn-based strategy without a lot of whizbang
> > stuff. In the past, the videos would stutter but the game would not
> > suffer from more than short pauses now and then.
>
>Yes, herein lies one of those mysteries that still eludes me but I have been
>investigating it. I can now reproduce in other applications what appears to
>be the problem - Two cpu hogs, X and evolution for example are running and
>evolution is making X the cpu hog. The problem is that X gets demoted whereas
>evolution doesn't. Strangely, dropping evolution to nice +1 or making X -1
>seems to change which one gets demoted, and X is now much smoother. I assume
>the same thing is happening here between wine and wineserver, which is why
>you've seen reversal of priorities in your previous posts. See if renicing
>one of them +1 helps for the time being. I will continue investigating to
>find out why the heck this happens and try and fix it.
>
>Con
>
>P.S. I've cc'ed MG because he has seen the scheduler do other forms of
>trickery and may have thoughts on why this happens.

That sounds suspiciously similar to my scenario, but mine requires a third 
element to trigger.

<scritch scritch scritch>

What about this?  In both your senario and mine, X is running low on cash 
while doing work at the request of a client right?  Charge for it.  If X is 
lower on cash than the guy he's working for, pick the client's pocket... 
take the remainder of your slice from his sleep_avg for your trouble.  If 
you're not in_interrupt(), nothing's free.  Similar to Robinhood, but you 
take from the rich, and keep it :)  He's probably going straight to the 
bank after he wakes you anyway, so he likely won't even miss it.  Instead 
of backboost of overflow, which can cause nasty problems, you could try 
backtheft.

         -Mike 

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Timothy Miller]

Mike Galbraith wrote:

> 
> That sounds suspiciously similar to my scenario, but mine requires a 
> third element to trigger.
> 
> <scritch scritch scritch>
> 
> What about this?  In both your senario and mine, X is running low on 
> cash while doing work at the request of a client right?  Charge for it.  
> If X is lower on cash than the guy he's working for, pick the client's 
> pocket... take the remainder of your slice from his sleep_avg for your 
> trouble.  If you're not in_interrupt(), nothing's free.  Similar to 
> Robinhood, but you take from the rich, and keep it :)  He's probably 
> going straight to the bank after he wakes you anyway, so he likely won't 
> even miss it.  Instead of backboost of overflow, which can cause nasty 
> problems, you could try backtheft.


How is this different from back-boost?

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Mike Galbraith]

At 02:44 PM 8/12/2003 -0400, Timothy Miller wrote:


>Mike Galbraith wrote:
>
>>That sounds suspiciously similar to my scenario, but mine requires a 
>>third element to trigger.
>><scritch scritch scritch>
>>What about this?  In both your senario and mine, X is running low on cash 
>>while doing work at the request of a client right?  Charge for it.
>>If X is lower on cash than the guy he's working for, pick the client's 
>>pocket... take the remainder of your slice from his sleep_avg for your 
>>trouble.  If you're not in_interrupt(), nothing's free.  Similar to 
>>Robinhood, but you take from the rich, and keep it :)  He's probably 
>>going straight to the bank after he wakes you anyway, so he likely won't 
>>even miss it.  Instead of backboost of overflow, which can cause nasty 
>>problems, you could try backtheft.
>
>
>How is this different from back-boost?

With backboost, you take everything that overflows MAX_SLEEP_AVG and give 
it all to the waker... you always pull-up.  With back-theft (blech;), 
there's constant pull-up and push-down for all parties instead of only 
those who reach MAX_SLEEP_AVG, so while you'll still tend to group tasks 
which are related (the original goal of backboost), it shouldn't (wild 
theory) go raging out of control.

         -Mike 

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Con Kolivas]

On Wed, 13 Aug 2003 04:24, Mike Galbraith wrote:
> At 12:40 AM 8/13/2003 +1000, Con Kolivas wrote:
> >On Wed, 13 Aug 2003 00:42, gaxt wrote:
> > > Photoshop 6 (yes, legal owned version) in wine is flawless (as it was
> > > with 2.6.0-test3)
> > >
> > > Galciv plays videos quite smoothly but as soon as I run it it will
> > > freeze the cursor for 12-15 seconds every half-minute or so even within
> > > the game itself which is turn-based strategy without a lot of whizbang
> > > stuff. In the past, the videos would stutter but the game would not
> > > suffer from more than short pauses now and then.
> >
> >Yes, herein lies one of those mysteries that still eludes me but I have
> > been investigating it. I can now reproduce in other applications what
> > appears to be the problem - Two cpu hogs, X and evolution for example are
> > running and evolution is making X the cpu hog. The problem is that X gets
> > demoted whereas evolution doesn't. Strangely, dropping evolution to nice
> > +1 or making X -1 seems to change which one gets demoted, and X is now
> > much smoother. I assume the same thing is happening here between wine and
> > wineserver, which is why you've seen reversal of priorities in your
> > previous posts. See if renicing one of them +1 helps for the time being.
> > I will continue investigating to find out why the heck this happens and
> > try and fix it.
> >
> >Con
> >
> >P.S. I've cc'ed MG because he has seen the scheduler do other forms of
> >trickery and may have thoughts on why this happens.
>
> That sounds suspiciously similar to my scenario, but mine requires a third
> element to trigger.
>
> <scritch scritch scritch>
>
> What about this?  In both your senario and mine, X is running low on cash
> while doing work at the request of a client right?  Charge for it.  If X is
> lower on cash than the guy he's working for, pick the client's pocket...
> take the remainder of your slice from his sleep_avg for your trouble.  If
> you're not in_interrupt(), nothing's free.  Similar to Robinhood, but you
> take from the rich, and keep it :)  He's probably going straight to the
> bank after he wakes you anyway, so he likely won't even miss it.  Instead
> of backboost of overflow, which can cause nasty problems, you could try
> backtheft.

Not a bad idea at all. The working for someone else thing is killing me. Now, 
how to implement...

Con

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Mike Galbraith]

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

At 01:34 PM 8/13/2003 +1000, Con Kolivas wrote:
>On Wed, 13 Aug 2003 04:24, Mike Galbraith wrote:
> > At 12:40 AM 8/13/2003 +1000, Con Kolivas wrote:
> > >On Wed, 13 Aug 2003 00:42, gaxt wrote:
> > > > Photoshop 6 (yes, legal owned version) in wine is flawless (as it was
> > > > with 2.6.0-test3)
> > > >
> > > > Galciv plays videos quite smoothly but as soon as I run it it will
> > > > freeze the cursor for 12-15 seconds every half-minute or so even within
> > > > the game itself which is turn-based strategy without a lot of whizbang
> > > > stuff. In the past, the videos would stutter but the game would not
> > > > suffer from more than short pauses now and then.
> > >
> > >Yes, herein lies one of those mysteries that still eludes me but I have
> > > been investigating it. I can now reproduce in other applications what
> > > appears to be the problem - Two cpu hogs, X and evolution for example are
> > > running and evolution is making X the cpu hog. The problem is that X gets
> > > demoted whereas evolution doesn't. Strangely, dropping evolution to nice
> > > +1 or making X -1 seems to change which one gets demoted, and X is now
> > > much smoother. I assume the same thing is happening here between wine and
> > > wineserver, which is why you've seen reversal of priorities in your
> > > previous posts. See if renicing one of them +1 helps for the time being.
> > > I will continue investigating to find out why the heck this happens and
> > > try and fix it.
> > >
> > >Con
> > >
> > >P.S. I've cc'ed MG because he has seen the scheduler do other forms of
> > >trickery and may have thoughts on why this happens.
> >
> > That sounds suspiciously similar to my scenario, but mine requires a third
> > element to trigger.
> >
> > <scritch scritch scritch>
> >
> > What about this?  In both your senario and mine, X is running low on cash
> > while doing work at the request of a client right?  Charge for it.  If X is
> > lower on cash than the guy he's working for, pick the client's pocket...
> > take the remainder of your slice from his sleep_avg for your trouble.  If
> > you're not in_interrupt(), nothing's free.  Similar to Robinhood, but you
> > take from the rich, and keep it :)  He's probably going straight to the
> > bank after he wakes you anyway, so he likely won't even miss it.  Instead
> > of backboost of overflow, which can cause nasty problems, you could try
> > backtheft.
>
>Not a bad idea at all. The working for someone else thing is killing me. Now,
>how to implement...

I had to back up and regroup a bit because of backboost sanity problems 
(wish I could pull those dang fangs, backboost is wonderful otherwise), but 
the attached cured my inversion problem.

         -Mike 

[-- Attachment #2: xx.diff --]
[-- Type: application/octet-stream, Size: 1400 bytes --]

--- linux-2.6.0-test1.G8/kernel/sched.c.org	Wed Aug 13 09:19:13 2003
+++ linux-2.6.0-test1.G8/kernel/sched.c	Wed Aug 13 14:41:42 2003
@@ -358,6 +358,8 @@
 
 	if (sleep_time > 0) {
 		unsigned long long sleep_avg;
+		unsigned long run_time = now - current->timestamp;
+		unsigned int slice = 1000000 * current->time_slice;
 
 		/*
 		 * This code gives a bonus to interactive tasks.
@@ -381,6 +383,22 @@
 			p->sleep_avg = sleep_avg;
 			p->prio = effective_prio(p);
 		}
+		/*
+		 * If the awakened task has been asleep for longer than the
+		 * waker has had the CPU plus round-robin time, and it is
+		 * going to preempt, there is a good chance that the waker
+		 * is not getting enough CPU to service the awakened task in
+		 * a timely manner, and that this is the cause of the preempt.
+		 * Take some of the resulting sleep_time from the awakened
+		 * task, and give it to the waker.
+		 */
+		if (!in_interrupt() && p->mm && current->mm && sleep_avg >
+				current->sleep_avg + slice && sleep_time > run_time +
+				(1000000 * this_rq()->nr_running * TIMESLICE_GRANULARITY) &&
+				TASK_PREEMPTS_CURR(p, task_rq(current))) {
+			current->sleep_avg += slice;
+			sleep_avg -= slice;
+		}
 	}
 }
 
@@ -1414,6 +1432,7 @@
 		next->timestamp = now;
 		rq->nr_switches++;
 		rq->curr = next;
+		next->timestamp = now;
 
 		prepare_arch_switch(rq, next);
 		prev = context_switch(rq, prev, next);

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Con Kolivas]

On Thu, 14 Aug 2003 04:45, Timothy Miller wrote:
> Voluspa wrote:
> > When the blackout starts I no longer have to move the mouse, it is
> > enough to hold down the button. The second I release it, the music
> > returns.
>
> I think this sort of thing has been discussed before.  I get the
> impression that xmms blocks on the X server, so when some app grabs the
> server, then xmms gets blocked and stops.  I don't know why the display
> code is not in a separate thread from the audio code; although maybe
> they are but they interact somehow that causes this.

This is a pure sheduler starvation issue which I'm trying to fix.

Con

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Timothy Miller]

Voluspa wrote:

> When the blackout starts I no longer have to move the mouse, it is
> enough to hold down the button. The second I release it, the music
> returns.


I think this sort of thing has been discussed before.  I get the 
impression that xmms blocks on the X server, so when some app grabs the 
server, then xmms gets blocked and stops.  I don't know why the display 
code is not in a separate thread from the audio code; although maybe 
they are but they interact somehow that causes this.

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Voluspa]

On Wed, 13 Aug 2003 07:15:22 +1000
Con Kolivas wrote:

> On Wed, 13 Aug 2003 01:23, Voluspa wrote:
> > On 2003-08-12 14:42:02 gaxt wrote:
> > Similar experience here running the game-test (xfree86 4.3.99.10,
> > winex 3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
> > 2.6.0-test3-O14.1int + O14.1-O15int.
> 
> Yes known issue for reason I mentioned. Currently investigating.

Yupp, you posted while I was writing.

> > I would say this is the best _and_ worst scheduler I've tried since
> > Con
> 
> Can you give us some idea what your machine is like when it's not
> running a cpu hog win32 game in wine? Also can you try running your
> game nice +1

As I've said, it is extremely hard for me to notice the scheduler unless
I run something graphic intensive, but my comments are of course not
solely based on that game-test. A general feel of smoothness can always
be attributed to the placebo effect, though I challenge anyone to
dispute the following experience.

Fourteen days ago I took home a precompiled Blender 2.28 - previous
copy of this 3D render program to reside here was 2.23. Grabbing the
grid which constitutes the world plane (hold third mouse button, drag)
and rotating it around the axes, I noticed something not present in the
old version. Jerks...

In kernel time this is 2.6.0-test1/2 and Cons O11int. Since then I've
done the "world rotate" on plain kernels and all O-patches without
noticing any improvement. Either mouse pointer or grid gets stuck for
about 1/2 to 2 seconds, making the movement unsynchronized. Can happen
while moving slowly, or spinning like crazy.

I don't have DRI with my mach64 (8 meg) because of choice, use Xv
instead, so I had made up my mind about the blame. Sloppy programming
and weak CPU.

Until O15int enters the mix. Perfect sync all the time, no matter how
slow, fast or long I rotate the world plane. That is why I call this
scheduler the "best". The "worst" part comes from the "known issue" but
also because I happened to run xmms on a directory of mp3s while
rotating. I got severe blackouts in the music, ca 10 - 15 seconds long.
When the blackout starts I no longer have to move the mouse, it is
enough to hold down the button. The second I release it, the music
returns.

Xmms has not been involved in the rotating before, so can't tell if the
blackouts have occurred. Could be due to the "known issue", but I'll
retest with older kernels when time permits.

Running the game-test with nice +1... Well, I tried that first on
wineserver, then wine, then X, after which I put -1 on them
consecutively. No real pattern emerged. Badness all around. And now I'm
falling asleep. Bye.

Mvh
Mats Johannesson

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Con Kolivas]

On Wed, 13 Aug 2003 01:23, Voluspa wrote:
> On 2003-08-12 14:42:02 gaxt wrote:
> Similar experience here running the game-test (xfree86 4.3.99.10, winex
> 3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
> 2.6.0-test3-O14.1int + O14.1-O15int.

Yes known issue for reason I mentioned. Currently investigating.

> I would say this is the best _and_ worst scheduler I've tried since Con

Can you give us some idea what your machine is like when it's not running a 
cpu hog win32 game in wine? Also can you try running your game nice +1

Con

Re: WINE + Galciv + 2.6.0-test3-mm1-O15

[Voluspa]

On 2003-08-12 14:42:02 gaxt wrote:

[...]
> Galciv plays videos quite smoothly but as soon as I run it it will
> freeze the cursor for 12-15 seconds every half-minute or so even
> within the game itself which is turn-based strategy without a lot of
> whizbang stuff. In the past, the videos would stutter but the game
> would not suffer from more than short pauses now and then.

Similar experience here running the game-test (xfree86 4.3.99.10, winex
3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
2.6.0-test3-O14.1int + O14.1-O15int.

I would say this is the best _and_ worst scheduler I've tried since Con
had to adopt his work to the new Ingo infrastructure. Slightly
smoother than pure A3 unless you manage to trigger badness. Then you (or
I, at least) get exactly 15 seconds of total freezes, mixed with
different periods of normality. And by freezes, I mean total freezes.

I can switch to an already opened text console, but there
a running "top" is dead and it won't take any keystrokes until the
freeze has gone. The only thing not dead is the "sound repeats" that
Daniel Phillips explained in:

http://marc.theaimsgroup.com/?l=linux-kernel&m=105966612027670&w=2

--quote--
To convince yourself of this, note that when DMA refill fails to meet
its deadline you will hear repeats, not skipping, because the DMA
hardware on the sound card has been set up to automatically restart the
DMA each time the buffer expires.  Try running the kernel under kgdb and
breaking to the monitor while sound is playing.
--unquote--

Mvh
Mats Johannesson