linux-kernel - volanoMark 24% regression in 2.6.24-rc6: why a simple patch makes it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1198559645.6362.195.camel@ymzhang>
Date:	Tue, 25 Dec 2007 13:14:05 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	travis@....com, LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org,
	suresh.b.siddha@...el.com, venkatesh.pallipadi@...el.com
Subject: volanoMark 24% regression in 2.6.24-rc6: why a simple patch makes
	it

With kernel 2.6.24-rc6, volanoMark has much regression.

1) On 8-core stoakley: 17%;
2) On 16-core tigerton: 24%.

I bisected it down to patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9. It is
to fix the bad cpu number in /proc/cpuinfo. As a matter of fact, this issue
is already fixed by other 2 patches:
699d934d5f958d7944d195c03c334f28cc0b3669
and
c0c52d28e05e8bdaa2126570c02ecb1a7358cecc.

At the first glance, the patch looks good, at least no conflict with the other
2 patches. After double-checking it, I found in below call chain:

smp_store_cpu_info => identify_cpu => init_intel => init_intel_cacheinfo.

When CONFIG_X86_HT=y, init_intel_cacheinfo will uses cpuinfo_x86->cpu_index, which
is initiated by smp_store_cpu_info. If with patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9,
cpuinfo_x86->cpu_index is initiated after identify_cpu is called, so
init_intel_cacheinfo just always initiates per_cpu(cpu_llc_id, 0) = l2_id or l3_id. Then,
set_cpu_sibling_map will set bad llc_shared_map, so the core domain won't be built.

By checking domain info from dmesg, it really confirms my consequence.

>>From this case, I really found that core domain could improve performance, at least when
testing by volanoMark. :)

The solution is just to revert patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9,
because other 2 patches which fixed the same issue are already in 2.6.24-rc5.

-yanmin

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