Re: smp wolk vs. java

Marc-Christian Petersen <[email protected]> Tue, 18 May 2004 21:47:00 +0200
Newsgroups gmane.linux.wolk.devel
Organization Linux-Systeme GmbH
Message-ID <200405182147.00919@WOLK>
On Tuesday 18 May 2004 20:58, Mike Bethune wrote:

Hey Mike,

> When running Java HotSpot Server VM (1.4.2), for example with tomcat or
> coldfusion: _always_ get memory related errors, here are a bunch of useless
> key words from the errors: Unexpected Signal : 11
> Heap at VM Abort
> java.lang.ArrayIndexOutOfBoundsException:
> java.lang.System.arraycopy
> java.lang.ArrayStoreException
> java.lang.OutOfMemoryError

uh? Strange.


> A redhat kernel with nothing else changed works fine,

Have fun with the fucked up VM in Redhat kernels ;p ... but appearently it 
does not have problems with SMP running java ;(


> also I have used the same wolk build and config but for single processor
> and it works fine. Have tried this on many servers with same results, but

oooh. Seems an SMP issue then.


> unfortunately due to time contraint I simply revert to using a redhat
> kernel on smp systems where I need to run java. I use a wolk kernel on more
> than 40 linux servers and have no other problems, just this.

wow. 40 servers? Cool :-)


> Sorry for the lack of info, but I will provide more if there's anything
> specific that would be helpful as long as I can do it quick :) Thanks,

I'd like to know if your P4 is a real SMP system or just HT? Could you please 
give this a test ride?

http://www.de.kernel.org/pub/linux/kernel/people/mcp/tmp/linux-2.4.20-wolk4.15s-pre19.patch.bz2

Please apply ontop of a 2.4.20 mainline kernel. Please report any success or 
fails. md5sum is: 6f940b9fa1bf56eb8fd3140f962646dc

Just some thoughts about the config:

1. Try disabling memory pools. Some reported strange issues with it.
   Personally I doubt anything changes with it disabled, but who knows.

2. Disable -Os compile option

3. How does your /proc/interrupts look like?

4. Just a note: Do you really have bcm5700, tg3 and e1000 cards in that
   machine? Beside that the first two drivers support almost the same cards ;)

5. I mean all the above with wolk/running wolk. Not rh or such.

6. BIG FAT NOTE: This 4.15 has a new config option, named CONFIG_HIGHPTE or in
   human readable ;) form: "Allocate 3rd-level pagetables from highmem".
   Select y and it's the default like all previos wolk had. If you still get
   strange errors with your JAVA with 4.15-pre19, disable CONFIG_HIGHPTE and
   please try again.

7. If nothing helps please apply the attached "test-1.patch" ontop of
   4.15s-pre19.

8. If you don't have a real SMP system but a P4 enabled HT cpu, please apply
   the attached "test-2.patch" ontop of 4.15s-pre19.

9. If 7.) and 8.) won't help, I am out of ideas _for the moment_ :)

10. Hint: less ./REPORTING-BUGS ;-))


P.S.: Some days ago I had funny errors with my machine. Updated to an P4 
2,8GHz HT enabled CPU and the kernel segfaulted all over the place during 
memory intensive things. First I thought it's my wolk, but it wasn't the 
case. All 2.4 kernels, 2.6 mainline, -mm, all segfaulted the same. Then I 
thought, my memory was too slow, verified that I really have 400MHz DDR RAM 
and I have it. After some time I thought looking for an bios update might help 
here and indeed, there was an update from ASUS. Flashed it and it works 
rock solid, very well w/o any segfaults since after the bios update.


Thanks.

ciao, Marc
test-1.patch (text/x-diff, 667 B)
--- old/arch/i386/kernel/io_apic.c	2004-05-18 13:25:29.000000000 +0200
+++ new/arch/i386/kernel/io_apic.c	2004-05-18 21:42:34.000000000 +0200
@@ -1368,7 +1368,6 @@ static unsigned int startup_edge_ioapic_
  */
 static void ack_edge_ioapic_irq(unsigned int irq)
 {
-	balance_irq(irq);
 	if ((irq_desc[irq].status & (IRQ_PENDING | IRQ_DISABLED))
 					== (IRQ_PENDING | IRQ_DISABLED))
 		mask_IO_APIC_irq(irq);
@@ -1408,7 +1407,6 @@ static void end_level_ioapic_irq (unsign
 	unsigned long v;
 	int i;
 
-	balance_irq(irq);
 /*
  * It appears there is an erratum which affects at least version 0x11
  * of I/O APIC (that's the 82093AA and cores integrated into various
test-2.patch (text/x-diff, 424 B)
--- old/kernel/sched.c	2004-05-18 17:30:16.000000000 +0200
+++ new/kernel/sched.c	2004-05-18 21:46:17.000000000 +0200
@@ -642,12 +642,6 @@ static void load_balance(runqueue_t *thi
 	list_t *head, *curr;
 	int resched;
 
-	/*
-	 * Handle architecture-specific balancing, such as hyperthreading.
-	 */
-	if (arch_load_balance(this_cpu, idle))
-		return;
-
  retry:
 	/*
 	 * We search all runqueues to find the most busy one.