2.6.0-testX - strange scheduling(?) problem

2.6.0-testX - strange scheduling(?) problem

[Murray J. Root]

P4 2G
1G PC2700 RAM
GF2 GTS video (nv drivers, not nvidia)

In all 2.6.0-test versions (1-5) I get very odd issues when using cpu+memory
intense apps. Using POV-Ray 3.5, for example:
When I render an image I get about 15k pixels per second and the system is
usable and responsive in other apps, most of the time.
About 20% of the time the pixels-per-second is only 3k, the system is at
nearly a standstill, and other apps barely function.
I've tested it many times using the exact same image and the behavior is
very consistent. Other apps do the same, but since I can't get a consistent
starting state with them, I used POV-Ray for the testing.
The slowdown is so bad that the screen can take as long as 2 seconds to 
refresh, opening a term can take as much as 15 seconds.
Stopping the render and restarting it fixes it about 1/2 the time. Stopping
the render and switching to another app, then restarting the render fixes
it about 1/2 the time. Enough stop & restarts always fixes it eventually.
There doesn't appear to be any memory leakage, and the system isn't going
into swap. Top shows the same numbers in all cases. Time of day, other 
apps running, etc. makes no difference.

-- 
Murray J. Root

Re: 2.6.0-testX - strange scheduling(?) problem

[Nick Piggin]

Murray J. Root wrote:

>On Wed, Sep 17, 2003 at 03:22:41PM +1000, Nick Piggin wrote:
>
>>
>>Murray J. Root wrote:
>>
>>
>>>P4 2G
>>>1G PC2700 RAM
>>>GF2 GTS video (nv drivers, not nvidia)
>>>
>>>In all 2.6.0-test versions (1-5) I get very odd issues when using 
>>>cpu+memory
>>>intense apps. Using POV-Ray 3.5, for example:
>>>When I render an image I get about 15k pixels per second and the system is
>>>usable and responsive in other apps, most of the time.
>>>About 20% of the time the pixels-per-second is only 3k, the system is at
>>>nearly a standstill, and other apps barely function.
>>>I've tested it many times using the exact same image and the behavior is
>>>very consistent. Other apps do the same, but since I can't get a consistent
>>>starting state with them, I used POV-Ray for the testing.
>>>The slowdown is so bad that the screen can take as long as 2 seconds to 
>>>refresh, opening a term can take as much as 15 seconds.
>>>Stopping the render and restarting it fixes it about 1/2 the time. Stopping
>>>the render and switching to another app, then restarting the render fixes
>>>it about 1/2 the time. Enough stop & restarts always fixes it eventually.
>>>There doesn't appear to be any memory leakage, and the system isn't going
>>>into swap. Top shows the same numbers in all cases. Time of day, other 
>>>apps running, etc. makes no difference.
>>>
>>>
>>Hi Murray,
>>Thanks for reporting this. Its a very important issue. Would you please
>>try this patch:
>>http://ck.kolivas.org/patches/2.6/2.6.0-test5/patch-test5-O20int
>>on 2.6.0-test5, and report your results.
>>
>>If you get time, or if the above still has problems, you could try
>>http://www.kerneltrap.org/~npiggin/v15/sched-rollup-v15.gz
>>as well. Give priority to the first patch though, please.
>>
>>
>
>Using the first patch either fixed it or made it so rare I haven't seen it
>in 4 hours of testing.
>One side-effect - rendering seems to take about 20% longer, and top shows
>X using 20-25% cpu while rendering. Prior to 2.6.0-test[1-5] X never got
>up past 5% and generally hung around less than 1%.
>But user-feel is *much* better. No delays or "hangs" while typing or clicking
>even while running two renders at the same time.
>

CCing to the list. Sounds good. The longer rendering seems to be pretty
well in line with the CPU X is using. This is obviously fine and
desired. Thanks Murray, and good news, this patch will be included in
test6 as far as I can see.

2.6.0-test5-bk8 breaks VMWare build

[J.C. Wren]

I don't know if this should be considered a VMWare or a kernel problem.  This works fine under 2.6.0-test3-bk8, so a header that VMWare depends on has changed.  The 
`__set_64bit_var': warning does occur in test3-bk8, but the module safely compiles.

None of VMware Workstation's pre-built vmmon modules is suitable for your
running kernel.  Do you want this program to try to build the vmmon module for
your system (you need to have a C compiler installed on your system)? [yes]

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.0-test5-bk8/build/include]

Extracting the sources of the vmmon module.

Building the vmmon module.

make: Entering directory `/tmp/vmware-config0/vmmon-only'
make[1]: Entering directory `/tmp/vmware-config0/vmmon-only'
make[2]: Entering directory `/tmp/vmware-config0/vmmon-only/driver-2.6.0-test5-bk8'
make[2]: Leaving directory `/tmp/vmware-config0/vmmon-only/driver-2.6.0-test5-bk8'
make[2]: Entering directory `/tmp/vmware-config0/vmmon-only/driver-2.6.0-test5-bk8'
In file included from /lib/modules/2.6.0-test5-bk8/build/include/asm/processor.h:18,
                 from /lib/modules/2.6.0-test5-bk8/build/include/asm/thread_info.h:13,
                 from /lib/modules/2.6.0-test5-bk8/build/include/linux/thread_info.h:21,
                 from /lib/modules/2.6.0-test5-bk8/build/include/linux/spinlock.h:12,
                 from /lib/modules/2.6.0-test5-bk8/build/include/linux/capability.h:45,
                 from /lib/modules/2.6.0-test5-bk8/build/include/linux/sched.h:7,
                 from /lib/modules/2.6.0-test5-bk8/build/include/linux/module.h:10,
                 from ../linux/driver.c:16:
/lib/modules/2.6.0-test5-bk8/build/include/asm/system.h: In function `__set_64bit_var':
/lib/modules/2.6.0-test5-bk8/build/include/asm/system.h:193: warning: dereferencing type-punned pointer will break strict-aliasing rules
/lib/modules/2.6.0-test5-bk8/build/include/asm/system.h:193: warning: dereferencing type-punned pointer will break strict-aliasing rules
../linux/driver.c: In function `init_module':
../linux/driver.c:246: error: structure has no member named `prev'
../linux/driver.c:247: error: structure has no member named `next'
../include/vm_asm.h: In function `Div643264':
../include/vm_asm.h:1095: warning: use of memory input without lvalue in asm operand 4 is deprecated
make[2]: *** [driver.o] Error 1
make[2]: Leaving directory `/tmp/vmware-config0/vmmon-only/driver-2.6.0-test5-bk8'
make[1]: *** [driver] Error 2
make[1]: Leaving directory `/tmp/vmware-config0/vmmon-only'
make: *** [auto-build] Error 2
make: Leaving directory `/tmp/vmware-config0/vmmon-only'
Unable to build the vmmon module.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.