Nick Piggin | 2 Feb 2004 00:36
Picon
Favicon

VM benchmarks

After playing with the active / inactive list balancing a bit,
I found I can very consistently take 2-3 seconds off a non
swapping kbuild, and the light swapping case is closer to 2.4.
Heavy swapping case is better again. Lost a bit in the middle
though.

http://www.kerneltrap.org/~npiggin/vm/4/

At the end of this I might come up with something that is very
suited to kbuild and no good at anything else. Do you have any
other ideas of what I should test?

Nick

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Andrew Morton | 2 Feb 2004 01:08

Re: VM benchmarks

Nick Piggin <piggin <at> cyberone.com.au> wrote:
>
> After playing with the active / inactive list balancing a bit,
> I found I can very consistently take 2-3 seconds off a non
> swapping kbuild, and the light swapping case is closer to 2.4.
> Heavy swapping case is better again. Lost a bit in the middle
> though.
> 
> http://www.kerneltrap.org/~npiggin/vm/4/
> 
> At the end of this I might come up with something that is very
> suited to kbuild and no good at anything else. Do you have any
> other ideas of what I should test?
> 

The thing people most seem to complain about is big compilations.

Things like a bitkeeper consistency check while dinking with the X UI have
also been noted, but that's a bit hard to quantify.

Maybe ask Roger to try his efax workload?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Nick Piggin | 2 Feb 2004 01:11
Picon
Favicon

Re: VM benchmarks


Andrew Morton wrote:

>Nick Piggin <piggin <at> cyberone.com.au> wrote:
>
>>After playing with the active / inactive list balancing a bit,
>>I found I can very consistently take 2-3 seconds off a non
>>swapping kbuild, and the light swapping case is closer to 2.4.
>>Heavy swapping case is better again. Lost a bit in the middle
>>though.
>>
>>http://www.kerneltrap.org/~npiggin/vm/4/
>>
>>At the end of this I might come up with something that is very
>>suited to kbuild and no good at anything else. Do you have any
>>other ideas of what I should test?
>>
>>
>
>The thing people most seem to complain about is big compilations.
>
>Things like a bitkeeper consistency check while dinking with the X UI have
>also been noted, but that's a bit hard to quantify.
>
>Maybe ask Roger to try his efax workload?
>
>
>

efax is a compilation as well. I would be up for trying it, but it
(Continue reading)

Martin J. Bligh | 2 Feb 2004 07:31

Re: VM benchmarks

> efax is a compilation as well. I would be up for trying it, but it
> needs quite a lot of GUI dev libraries installed to compile it.
> I'll get onto it sometime I suppose, but for now I'll try to leave
> my test box unchanged.
> 
> Unfortunately starting mozilla / kde / openoffice is another one
> people complain about but harder to test...

Maybe you could just get gentoo to compile the whole distro ;-)

What kind of parallelism are you putting into make?

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Nick Piggin | 2 Feb 2004 08:51
Picon
Favicon

Re: VM benchmarks


Martin J. Bligh wrote:

>>efax is a compilation as well. I would be up for trying it, but it
>>needs quite a lot of GUI dev libraries installed to compile it.
>>I'll get onto it sometime I suppose, but for now I'll try to leave
>>my test box unchanged.
>>
>>Unfortunately starting mozilla / kde / openoffice is another one
>>people complain about but harder to test...
>>
>
>Maybe you could just get gentoo to compile the whole distro ;-)
>
>What kind of parallelism are you putting into make?
>
>

On the graph here: http://www.kerneltrap.org/~npiggin/vm/4/
the x axis is the -j factor, and I'm compiling a 2.4.21
source with gcc 3.3 booting with mem=64M.

You can see it just starts to swap at -j6 and I'm going up
to -j16 which is then fairly heavy swapping (takes >20minutes).

Another thing that will need looking at is non swapping
pagecache performance of course.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
(Continue reading)

Roger Luethi | 2 Feb 2004 17:50
Picon
Favicon

Re: VM benchmarks

On Mon, 02 Feb 2004 11:11:46 +1100, Nick Piggin wrote:
> efax is a compilation as well. I would be up for trying it, but it

The main advantage of efax over kbuild is that it is completely immune
to unfairness. And it used to have a low variance (in 2.4). Other than
that, access patterns are similar enough to make me suspect that gcc
loads are all quite similar.

> needs quite a lot of GUI dev libraries installed to compile it.
>
> I'll get onto it sometime I suppose, but for now I'll try to leave
> my test box unchanged.

You can actually do something like which shouldn't require the
dependencies on the test box:

/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.3/cc1plus -fpreprocessed efaxi586.ii \
-quiet -O2 -Wall -fexceptions -frtti -fsigned-char -fno-check-new -o main.s

All you need is the preprocessed code.

I can test a couple of patches I you care, though. Which ones?

Roger
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

(Continue reading)

Nick Piggin | 3 Feb 2004 00:17
Picon
Favicon

Re: VM benchmarks


Roger Luethi wrote:

>On Mon, 02 Feb 2004 11:11:46 +1100, Nick Piggin wrote:
>
>>efax is a compilation as well. I would be up for trying it, but it
>>
>
>The main advantage of efax over kbuild is that it is completely immune
>to unfairness. And it used to have a low variance (in 2.4). Other than
>that, access patterns are similar enough to make me suspect that gcc
>loads are all quite similar.
>
>
>>needs quite a lot of GUI dev libraries installed to compile it.
>>
>>I'll get onto it sometime I suppose, but for now I'll try to leave
>>my test box unchanged.
>>
>
>You can actually do something like which shouldn't require the
>dependencies on the test box:
>
>/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.3/cc1plus -fpreprocessed efaxi586.ii \
>-quiet -O2 -Wall -fexceptions -frtti -fsigned-char -fno-check-new -o main.s
>
>

Could you zip up the preprocessed file and send it to me if possible
please? (off list of course)
(Continue reading)

Alok Mooley | 3 Feb 2004 05:46
Picon
Favicon

Active Memory Defragmentation: Our implementation & problems

/*
* Active Memory Defragmentation
*/
#include<linux/asap.h>

#include"AMD.h"

MODULE_LICENSE("GPL");

/*
* This is the order till which the block freed went
* (for debugging)
*/
static int cnt_order;
/*
*This is the init module
*/
static int amd_init(void)
{
	int order = ORDER;
        printk("\nModule: AMD loaded\n");
#ifdef CALL_FROM_HERE
	/*
	 * Personally call the module
	 */
	defrag(order,zone_table[ZONE_NORMAL]);
#else
	/*
	 * The buddy allocator calls the module just before fallback
	 */
(Continue reading)

Andrew Morton | 3 Feb 2004 08:58

2.6.2-rc3-mm1

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc3/2.6.2-rc3-mm1/

- There is a debug patch in here which detects when someone calls
  i_size_write() without holding the inode's i_sem.  It generates a warning
  and a stack backtrace.  We know that XFS generates such a trace.  It will
  turn itself off after the first ten warnings.  Please don't report the XFS
  case.

- Added the CPU hotplug code.

- This kernel is currently broken on ppc64.  Something to do with the
  sched-domains patch although at this stage we do not know whether the
  problem lies with that patch or with the ppc64 code.

- A big Altix update

- Latest versions of various other developers' trees.  See below for
  details.

- Various other fixes

Changes since 2.6.2-rc2-mm2:

 linus.patch

 Latest Linus tree

 bk-alsa.patch

 Latest ALSA tree
(Continue reading)

Prakash K. Cheemplavam | 3 Feb 2004 10:58
Picon
Picon

Re: 2.6.2-rc3-mm1

Hi,

I am getting this on init. I think while udev inits:

i_size_write() called without i_sem
Feb  3 10:53:53 tachyon Call Trace:
Feb  3 10:53:53 tachyon [<c013d347>] i_size_write_check+0x57/0x60
Feb  3 10:53:53 tachyon [<c01767de>] simple_commit_write+0x3e/0xa0
Feb  3 10:53:53 tachyon [<c0167f3c>] page_symlink+0xec/0x1dd
Feb  3 10:5i_size_write() called without i_sem
Feb  3 10:53:53 tachyon Call Trace:
Feb  3 10:53:53 tachyon [<c013d347>] i_size_write_check+0x57/0x60
Feb  3 10:53:53 tachyon [<c01767de>] simple_commit_write+0x3e/0xa0
Feb  3 10:53:53 tachyon [<c0167f3c>] page_symlink+0xec/0x1dd
Feb  3 10:53:53 tachyon [<c01bbbdd>] ramfs_symlink+0x5d/0xc0
Feb  3 10:53:53 tachyon [<c0166e37>] vfs_symlink+0x57/0xb0
Feb  3 10:53:53 tachyon [<c0166f63>] sys_symlink+0xd3/0xf0
Feb  3 10:53:53 tachyon [<c038fa86>] sysenter_past_esp+0x43/0x65
3:53 tachyon [<c01bbbdd>] ramfs_symlink+0x5d/0xc0
Feb  3 10:53:53 tachyon [<c0166e37>] vfs_symlink+0x57/0xb0
Feb  3 10:53:53 tachyon [<c0166f63>] sys_symlink+0xd3/0xf0
Feb  3 10:53:53 tachyon [<c038fa86>] sysenter_past_esp+0x43/0x65

This appears about 10 times. I haven't teste the kernel further.

.config attached

dmesg:

Feb  3 10:53:53 tachyon Linux version 2.6.2-rc3-mm1 (root <at> tachyon) 
(Continue reading)


Gmane