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
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.
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.
On 22 Sep 03 at 0:48, J.C. Wren wrote:
> 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.
As usual. Get update from http://platan.vc.cvut.cz/ftp/pub/vmware,
currently vmware-any-any-update40.tar.gz. __set_64bit_var was fixed
in update37, and recent misc_device changes in update40.
> /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
This one is fixed too. I believe that since update37 too, but I'm
not 100% sure.
[OT] And I'm not sure that this one is actually correct warning
from gcc, as it looks completely bogus to me. Gcc even correctly
understood that it must save dividend to the memory to satisfy rules,
but "(uint32)dividend" is good enough lvalue for left side in assignment,
yet it is not enough "lvalued" for asm constraint... And if
it could decide for "i" choice from "mi", it would be perfect...
Best regards,
Petr Vandrovec
#define ORIG
typedef unsigned int uint32;
typedef unsigned long long uint64;
static inline void
Div643232(uint64 dividend, // IN
uint32 divisor, // IN
uint32 *quotient, // OUT
uint32 *remainder) // OUT
{
/* Checked against the Intel manual and GCC --hpreg */
__asm__(
"divl %4"
: "=a" (*quotient),
"=d" (*remainder)
: "0" ((uint32)dividend),
"1" ((uint32)(dividend >> 32)),
"rm" (divisor)
: "cc"
);
}
static inline void
Div643264(uint64 dividend, // IN
uint32 divisor, // IN
uint64 *quotient, // OUT
uint32 *remainder) // OUT
{
uint32 hQuotient;
uint32 lQuotient;
/* Checked against the Intel manual and GCC --hpreg */
__asm__(
"divl %5" "\n\t"
"movl %%eax, %0" "\n\t"
"movl %4, %%eax" "\n\t"
"divl %5"
#ifdef ORIG
: "=m" (hQuotient),
"=a" (lQuotient),
"=d" (*remainder)
: "1" ((uint32)(dividend >> 32)),
"mi" ((uint32)dividend),
"rm" (divisor),
"2" (0)
: "cc"
#else
: "=&rm" (hQuotient),
"=a" (lQuotient),
"=d" (*remainder)
: "1" ((uint32)(dividend >> 32)),
"g" ((uint32)dividend),
"rm" (divisor),
"2" (0)
: "cc"
#endif
);
*quotient = (uint64)hQuotient << 32 | lQuotient;
}
uint32
Vmx86_GetkHzEstimate(void) // IN: start time
{
uint64 hz;
uint32 tmp;
uint32 tmpkHz;
Div643264(2222, 333, &hz, &tmp);
Div643232(hz + 500, 1000, &tmpkHz, &tmp);
return tmpkHz;
}
/*
platan:/tmp/x# gcc -W -Wall -O2 -c vmx86.c
vmx86.c: In function `Vmx86_GetkHzEstimate':
vmx86.c:34: warning: use of memory input without lvalue in asm operand 4 is deprecated
vmx86.c: In function `Div643264':
vmx86.c:34: warning: use of memory input without lvalue in asm operand 4 is deprecated
gcc version 3.3.2 20030908 (Debian prerelease)
*/