Re: Clear performance regression on reaim7 in 2.6.15-git6

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Andrew Morton <akpm@osdl.org> writes:

> "Martin J. Bligh" <mbligh@google.com> wrote:
>>
>> drilling down into the results directories can get you the command line,
>>  looks like "reaim -f workfile.short -s 1 -e 10 -i 2" to me. Buggered if
>>  I can recall what that did though.
>> 
>>  (http://test.kernel.org/abat/20229/004.reaim.test/results/cmdline)
>> 
>>  I *think* it's only ia32 NUMA boxes, at least as far as I can see from
>>  a quick poke around. Which would make me guess at scheduler code. Gitweb
>>  would be nice to use, but it doesn't tag the -git snapshots, AFAICS, 
>>  which is a real shame. Nor does the git snapshot include the git tag,
>>  as far as I know. Grrrr. I guess I'll download the snapshots and diff
>>  them, and try to pull out the sched changes by hand. Much suckage.
>
> The diffstat for 2.6.15-git5 -> 2.6.15-git6 is at
> http://www.zip.com.au/~akpm/linux/patches/stuff/2 - only a single line
> changed in sched.c:
>
> diff -uNr 2.6.15-git5/kernel/sched.c 2.6.15-git6/kernel/sched.c
> --- 2.6.15-git5/kernel/sched.c	2006-04-15 14:10:43.000000000 -0700
> +++ 2.6.15-git6/kernel/sched.c	2006-04-15 14:10:52.000000000 -0700
> @@ -4386,6 +4386,7 @@
>  	} while_each_thread(g, p);
>  
>  	read_unlock(&tasklist_lock);
> +	mutex_debug_show_all_locks();
>  }
>  
>  /**
>
> The below patches went from -mm into mainline on that day.  It'll be pretty
> simple to bisection search these once we have a testcase.

config DEBUG_MUTEXES
	bool "Mutex debugging, deadlock detection"
	default y
	depends on DEBUG_KERNEL
	help
	 This allows mutex semantics violations and mutex related deadlocks
	 (lockups) to be detected and reported automatically.

?

By default, it's y, so it seems likely.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>