Message-ID: <3F26E36B.2050709@rogers.com>
Date: Tue, 29 Jul 2003 17:13:15 -0400
From: gaxt <gaxt@rogers.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030727 Thunderbird/0.1
MIME-Version: 1.0
To: Con Kolivas <kernel@kolivas.org>
CC: linux-kernel@vger.kernel.org
Subject: Re: WINE + Galciv + Con Kolivas's 011 patch to  2.6.0-test2
References: <3F22F75D.8090607@rogers.com> <200307291325.09096.kernel@kolivas.org> <3F266D33.4040106@rogers.com> <200307292246.36808.kernel@kolivas.org> <3F26E044.9010202@rogers.com> <3F26E2A5.3020303@rogers.com>
In-Reply-To: <3F26E2A5.3020303@rogers.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2893
Lines: 78

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


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