On Thu, May 15, 2008 at 01:29:59PM -0600, Matthew Wilcox wrote: > On Thu, May 15, 2008 at 12:09:06PM -0700, Christoph Lameter wrote: > > Assumptions may be the issue. My own "reproducer" for remote frees is > > available from my git tree and I usually prefer to run my own. We > > No doubt you prefer to run a test which fails to show a problem with > your code. How about you try running a test which does show a problem? This is rather interesting. Since Christoph refuses to, here's my results with 8f40f67, first with slab: willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 0 completed 1000000 ops in 52.817 seconds; 18933 ops per second CPU 2 completed 1000000 ops in 56.391 seconds; 17733 ops per second CPU 3 completed 1000000 ops in 57.009 seconds; 17541 ops per second CPU 1 completed 1000000 ops in 57.591 seconds; 17363 ops per second willy@piggy:~$ sudo taskset -p 1 941 pid 941's current affinity mask: f pid 941's new affinity mask: 1 willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 2 completed 1000000 ops in 46.740 seconds; 21394 ops per second CPU 0 completed 1000000 ops in 48.716 seconds; 20527 ops per second CPU 3 completed 1000000 ops in 59.255 seconds; 16876 ops per second CPU 1 completed 1000000 ops in 60.473 seconds; 16536 ops per second (the pid is that of scsi_ram_0) Now, change the config to slub: --- 64-slab/.config 2008-05-15 15:21:31.000000000 -0400 +++ 64-slub/.config 2008-05-15 15:37:45.000000000 -0400 -# Thu May 15 15:21:31 2008 +# Thu May 15 15:37:45 2008 -CONFIG_SLAB=y -# CONFIG_SLUB is not set +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y -# CONFIG_DEBUG_SLAB is not set +# CONFIG_SLUB_DEBUG_ON is not set +# CONFIG_SLUB_STATS is not set and we get slightly better results: willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 0 completed 1000000 ops in 45.848 seconds; 21811 ops per second CPU 2 completed 1000000 ops in 50.789 seconds; 19689 ops per second CPU 3 completed 1000000 ops in 55.876 seconds; 17896 ops per second CPU 1 completed 1000000 ops in 56.941 seconds; 17562 ops per second willy@piggy:~$ sudo taskset -p 1 1001 pid 1001's current affinity mask: f pid 1001's new affinity mask: 1 willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 2 completed 1000000 ops in 45.713 seconds; 21875 ops per second CPU 0 completed 1000000 ops in 47.020 seconds; 21267 ops per second CPU 3 completed 1000000 ops in 58.692 seconds; 17038 ops per second CPU 1 completed 1000000 ops in 60.389 seconds; 16559 ops per second Slub's clearly in the lead, right? Maybe. Here's the results we get with 2.6.25+slab: willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 3 completed 1000000 ops in 48.709 seconds; 20530 ops per second CPU 1 completed 1000000 ops in 50.181 seconds; 19927 ops per second CPU 0 completed 1000000 ops in 53.511 seconds; 18687 ops per second CPU 2 completed 1000000 ops in 54.169 seconds; 18460 ops per second willy@piggy:~$ sudo taskset -p 1 930 pid 930's current affinity mask: f pid 930's new affinity mask: 1 willy@piggy:~$ sudo ./io-gen -d /dev/sda -j4 CPU 2 completed 1000000 ops in 40.568 seconds; 24649 ops per second CPU 0 completed 1000000 ops in 47.986 seconds; 20839 ops per second CPU 3 completed 1000000 ops in 55.944 seconds; 17875 ops per second CPU 1 completed 1000000 ops in 56.180 seconds; 17799 ops per second I think I'm going to try backing out some of the recent patches that have gone into /slab/ and see if it's been regressing. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
