On Fri, Mar 09, 2007 at 02:46:24PM -0600, Matt Mackall wrote: > A priori, this load should be manageable by RSDL as the interactive > loads are all pretty small. So I wrote a little Python script that > basically continuously memcpys some 16MB chunks of memory: > > #!/usr/bin/python > a = "a" * 16 * 1024 * 1024 > while 1: > b = a[1:] + "b" > a = b[1:] + "c" > > I've got 1.5G of RAM, so I can run quite a few of these without > killing my pagecache. This should test whether a) Beryl's actually > running up against memory bandwidth issues and b) whether "simple" > static loads work. As you can see, running 5 instances of this script > leaves me in good shape still. 10 is still in "ok" territory, with top > showing each getting 9.7-10% of the CPU. 15 starts to feel sluggish. > 20 the mouse jumps a bit and I got an MP3 skip. 30 is getting pretty > bad, but still not as bad as the make -j 5 load. > > My suspicion is the problem lies in giving too much quanta to > newly-started processes.
I've also tried 10+ instances of each of the following: forkload: #!/bin/sh ./forkload& execload: #!/bin/sh exec ./execload And it's quite well-behaved in both cases. Also, if I run: for a in 1 2 3 4 5; do mkdir $a; cp .config $a; make O=$a & done ..I get mostly good behavior with some occassional snags. Things run much better than make -j 5. Unfortunately, that doesn't make my kernel get built faster. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/