Re: 2.6.1 slower than 2.4, smp/scsi/sw-raid/reiserfs

From: Nick Piggin
Date: Mon Feb 02 2004 - 18:38:09 EST




Philip Martin wrote:

Nick Piggin <piggin@xxxxxxxxxxxxxxx> writes:


Another thing I just saw - you've got quite a lot of memory in
buffers which might be something going wrong.

When the build finishes and there is no other activity, can you
try applying anonymous memory pressure until it starts swapping
to see if everything gets reclaimed properly?


How do I apply anonymous memory pressure?



Well just run something that uses a lot of memory and doesn't
do much else. Run a few of these if you like:

#include <stdlib.h>
#include <unistd.h>
#define MEMSZ (64 * 1024 * 1024)
int main(void)
{
int i;
char *mem = malloc(MEMSZ);
for (i = 0; i < MEMSZ; i+=4096)
mem[i] = i;
sleep(60);
return 0;
}

Was each kernel freshly booted and without background activity
before each compile?


Each kernel was freshly booted. There were a number of daemons
running, and I was running X, but these don't appear to use much
memory or CPU and the network was disconnected. Just after a boot
there is lots of free memory, but in normal operation the machine uses
its memory, so to make it more like normal I ran "find | grep" before
doing the build. Then I ran make clean, make, make clean, make and
took numbers for the second make.

You can have the numbers straight after a boot as well. In this case
I rebooted, logged in, ran make clean and make -j4.

I can hear disk activity on this machine. During a 2.4.24 build the
activity happens in short bursts a few seconds apart. During a 2.6.1
build it sounds as if there is more activity, with each burst of
activity being a little longer. However that just the impression I
get, I haven't tried timing anything, I may be imagining it.



Thanks. Much the same, isn't it?
Can you try booting with the kernel argument: elevator=deadline
and see how 2.6 goes?

Andrew, any other ideas?

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